Making upgrading more reliable

I recently tried to upgrade from 3.2 to 3.3 and had the database migration fail. Now, the database migration always fails, so I tried to do what I usually do and go through the database migration steps manually one by one, fixing any that fail until the db is fully migrated. But with the switch to using Illuminate migrations it’s very difficult to translate these into SQL statements that I can run manually.

The ideal solution for me would be to ship with a set of migration SQL scripts for each supported database so I can run them manually rather than using the Illuminate code. Is this possible?

Hi @garethbowen,

The Illuminate/Database migrations toolset (and underlying that, the query builder) is a much more modern toolset and we’ll be deploying it more and more in the future. So to answer your immediate question, no, we won’t be shipping with a set of raw SQL queries that describe the upgrade.

On the other hand, part of the goal of this change is to make upgrades quicker and more reliable, and it does allow for the separate execution of migrations (using lib/pkp/tools/migration.php). As our refinement in using this toolset increases and we knit it further into the codebase I expect there will be positive impacts on e.g. recoveries from failed upgrades.

However, I suspect you have some data problems that are the underlying cause of your upgrade troubles; I’d recommend focusing on those to get your database cleaned up. Then, regardless of tooling, upgrades will be much less painful.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

Thanks for your response, and you’re absolutely right that there’s probably an issue in our data somewhere. The challenge I have is the tooling makes it very difficult to clean it up because it doesn’t report on which step of the upgrade failed, and if you do find the error it’s near impossible to work out what it was trying to do and therefore which data needs to be corrected.

Is there any way to validate the data?

Can I clean up the data by exporting from 3.2 and importing into a fresh 3.3?

Hi @garethbowen,

The best guidance in identifying the data problem is the error message when you attempt an upgrade. (That’s only true of the first attempt at an upgrade – if you run an upgrade a second time without restoring from backup, you’ll get a different error, caused by the system trying to re-run steps it’s already run – so it’s important to have a good backup and grab the error message on a first upgrade attempt.)

Regards,
Alec Smecher
Public Knowledge Project Team