What directories should be preserved in a OJS update?
I’m currently using OJS 2.4.3.0, my current setup is some problems and i want to do a full upgrade.
Hi @Angelo_Rocha,
See here: http://pkp.sfu.ca/ojs/UPGRADE, specially item 3, I think that’s your case.
Cheers,
Bruno
I´m tryng to upgrade from OJS 2.3.7 to 2.4.6, I did but when I try to upgrade database it gives me a mistake about Duplicate entries for key ‘article_search_keyword_text’
like this: Duplicate entry ‘fanerófitas’ for key ‘article_search_keyword_text’
may you help me on this?? thanks very much.
You can safely delete the contents of article_search_keyword_list, article_search_object_keywords, and article_search_objects before upgrading – these tables contain the full-text search index and can be re-generated afterwards by running php tools/rebuildSearchIndex.php.
However, it’s worth checking your character set configuration to make sure you aren’t accidentally changing something; make sure those parts of your config.inc.php match your old version.
Regards,
Alec Smecher
Public Knowledge Project Team
1 Like
Regenerating these tables is taking several days on a development server here (where we have about half the content of production!) and has slowed the site down while chugging away.
Do you have any suggestions for a workflow to regenerate these? Or can the reindexing be tripped off one journal at a time for a site hosting multiple journals?
Best,
-Wilhelmina
Wilhelmina Randtke
Digital Library Services and Open Educational Resources Coordinator
Florida Academic Library Services Cooperative
Gainesville, FL 32606
wrandtke@flvc.org
Hi @randtke,
The indexing does happen one journal at a time, though the reindexing script is currently set to go through them all, rather than e.g. letting you specify a specific journal to re-index. Generally it’s not necessary to run the script, as the site should maintain its index as it goes. It’s for cases where the index gets corrupted, e.g. by a character set issue or a change to the indexing tools in config.inc.php.
If it’s slowing down the production site, that’s probably happening at the MySQL (or PostgreSQL) level. Two thoughts come to mind, neither particularly good…
- Add an artificial delay between article indexing operations to decrease load, at the cost of making the re-index take longer.
- Disable the database indexes (on
submission_search_...tables) before running the reindex, then recreate them all at once afterwards. You’ll definitely want to temporarily disable the search interface while you do this, as it’ll become extremely server-intensive!
Regards,
Alec Smecher
Public Knowledge Project Team
Thanks for the info.
We ran the full text reindexing and it actually was chugging away for about a week on the development server and then interrupted because of restarting during a maintenance window. I did try and run some searches while the script was chugging away, which it sounds like would slow the site down.
My guess is that reindexing all at once on the production site would be pretty disruptive.
Are those tables used for anything else other than the search box along the top of pages on the OJS site? Would anything other than full text search be affected if we skipped the rows with the “Duplicate entry” problem?
Best,
-Wilhelmina
Hi @randtke,
Nothing other than the search index makes use of the article_search_keyword_list , article_search_object_keywords , and article_search_objects tables.
The Duplicate entry warnings are probably caused by a character set problem – OJS checks to see whether any entries exist, and if not, it tries to run the insert. If OJS and MySQL have different character set configurations this can lead to confusion over what a duplicate actually is. I’d suggest reviewing your character set configs both in OJS and MySQL to make sure they match.
Otherwise, no, skipping those entries will not cause problems (though I do recommend correcting any charset problems).
Regards,
Alec Smecher
Public Knowledge Project Team