After downloading and unzipping the last version of OJS I try to execute the Command-line php tools/upgrade.php upgrade to upgrade my database. I get the following result
For the patch-based upgrade, there should be some error messages above what you’ve quoted indicating which patch files failed to apply. Once you’ve got the patch applied, you’ll still need to upgrae the database, which is the part that stalled in the second attempt.
For the second attempt, did you get dumped back to the command line, or did you just stop getting feedback? You might need to leave that running for quite a while. If you do attempt it again, make sure you restore your database from backup, because an interrupted database upgrade will leave your database in an inconsistent state.
The notifications system in 2.3.x isn’t particularly crucial, so you can always try to skip that step by deleting the contents of the notifications table before running the upgrade. You shouldn’t run into trouble.
Regards,
Alec Smecher
Public Knowledge Project Team
For the patch-based upgrade I didn’t notice which patch files failed, I used the tool for automatic download of appropriate patch with command php tools/upgrade.php patch.
For the second attempt, instead, I didn’t back to the command line. I had to close my shell window and open a new section in the server to access to command line. I tried to leave the process for hours without results.
I’ll try to remove the contents in notification table.
Now it works! I removed the contents in notification table (more than 430000 lines, hope useless) and the upgrade has been fine.
Thank you very very much.
Great, glad to hear it worked. With that many notifications it’s entirely plausible that the upgrade was still running, just slowly. But you won’t run into any problems with notifications removed.
Regards,
Alec Smecher
Public Knowledge Project Team
I did the entire upgrade fixing errors, and I documented everything. To follow these steps, your database and code need to be clean. (You cannot have tried updating them before. Ever remembering to restore the database after errors during database upgrading. To do it, you need to have the all magazine backup). In my case I do 2.3.6 to 2.4.8-1 upgrade. I hope it helps someone…
Step by step (This will test your system to upgrade - If you have message Hunk #11 FAILED at 420 it’s because your config.inc.php was changed. No problems, you’ll just get config.TEMPLATE.inc.php duplicate and put the configuration informations on it, renaming it too to config.inc.php after that.) patch -p1 --dry-run < PATCH-FILE
After that patch -p1 < PATCH-FILE
After the steps before your code was upgraded, but not your database.
So when you upgrade your database, first edit the Core.inc.php file in lib/pkp/classes/core: date_default_timezone_set(‘MyContinent/MyZone’);
Add it before the Class statement, you can see the timezone list here
When you’ll need to alter some things on your database, before the effective upgrade. Execute this SQL. # Do it before upgrade the database!! USE my-ojs-database; # Upgrade failed: DB: Incorrect table definition; there can be only one auto column and it must be defined as a key ALTER TABLE review_rounds ADD review_round_id BIGINT(20) NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST; # DB Error: Table orbital.notification_settings_old doesnt exist CREATE TABLE notification_settings_old SELECT * FROM notification_settings;
Finnally upgrading our database php tools/upgrade.php check
If you have no errors or warnings php tools/upgrade.php upgrade
Sorry, I’m not really good with English, but I hope you understand guys.
This is an old tread but I ran into the same problem where upgrading halts without errors after the
[code: Installer Installer::migrateNotifications]
line when upgrading from 2.3.8 to 2.4.8 (as first step in the upgrade to 3.1.1)
The system seems to work just fine, but when trying to do the next upgrade step from 2.4.8 to 3.1.1 the upgrade script immediately stops, telling me my database is still in version 2.3.8.
.
I had 250k records in the notifications_old table. There is a select all query and a loop going through all notifications in migrateNotifications and that needs a lot of memory it seems. After halting, the new notifications table was still empty.
Raising the memory_limit setting (Maximum amount of memory a script may consume) from 128M to 512M in php.ini solved the problem.