Hi guys.
I´ve been reading this forum from a long time and this is my first topic (I hope I´m not breaking any rules).
So I just successfully upgraded our sandbox OJS from 3.1.2.1 → 3.3.0.20 → 3.4.0.8. I did encountered some problems along the way but it was all solved with the help of this forum. The upgraded OJS is not fully tested, but it seems to be operating correctly.
But then I restored our sandbox to 3.1.2.1 and tried to upgrade directly to 3.4.0.8. The problem I´m facing is already mentioned here. It seems to be resolved when upgrading directly to 3.3.x.x but not to 3.4.x.x.
So before upgrading to 3.4.0.8, I edited the file dbscripts/xml/upgrade.xml just like this and this problem was solved.
Is it ok to do this when upgrading to 3.4.0.8? If yes, should this fix be commited in the next 3.4.x.x releases?
Hi @lucas08,
No rules broken!
Is it possible that you’re reloading the database dump from backup without first dropping and re-creating the database? If so, then you might have a submission_galley_settings lying around before you run the upgrade, which would collide with the upgrade process when it tries to create a new one.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher, thanks for your replay.
Actually, the submission_galley_settings table also exists on our production OJS (3.1.2.1), so we do have the table in our dump before the upgrade too. Is it secure to delete this table before upgrading to 3.4.0.8?
By the way, our database also contain some articles tables that I believe are not used in 3.1.2.1 or higher, am I right? Is it ok to delete those too?
Hi @lucas08,
You’re right, OJS 3.1.2-1 did include reference to a submission_galley_settings table – my recollection that far back is pretty foggy.
May I ask why you don’t just upgrade to 3.3.0-x as an interim step? That’s a very well-trodden path and it sounds like it’s worked for you.
Regards,
Alec Smecher
Public Knowledge Project Team
This topic was automatically closed after 9 days. New replies are no longer allowed.
