auge8472
commented
1 year ago And here we are again. After reworking the update script in #643 tests showed, that the update does break under special circumstances. The current problem is the test for doubled e-mail-addresses. If a doubled address is found, the script stops at this point. So far, so correct.
But until then the script changed several things and leaves the forum in an twilight state with several changes in the database structure but several remaining and undone tasks. The problem is, in its current state, the script cannot be run again to complete only the rest of the tasks. So the forum ends in a broken state.
In my test to update a forum from version 2.4.24 to the current development branch, intentionally provided with a duplicate e-mail-address, the form tells me, that there is a doublette. Afterwards the old (not upgraded) script files throws errors about errors because of broken database queries (the queries in the scripts does not know anything about the partially changed database structure). After upgrading the script files, the forum tells me, that there are no entries and threads because the necessary changes regarding the new tables for spam protection, that are part of the update script was not executed because of the test for doubled e-mail-addresses.
Long story short, the upgrade process overwhelmed me because of its complexity. My proposal is to rebuild the update script again to contain a complete path from any starting point to the current version with the price of many repeatings for the several starting points. That would make it possible to perform all necessary checks at the beginning of the upgrade process independently from its actual position in the process.
To describe an example: The check for doubled e-mail-addresses is necessary because of the changed definition of mlf2_userdata.user_email as unique. This change came with version 2.4.99.2. With a complete update script for any starting point, it is possible to perform the check before starting with any change for the starting point versions 2.4.19.1 up to 2.4.24.
I'll present a PR within the next days.
When the update script runs the database operations, it is possible for the update script to break somewhen in the middle of the task (typically because of a database error). At this point several of the operations may ran successful and only a few undone operations left over. At that point the database may be in an undefined version state that makes it impossible to run the forum with the old and the new version. This is a problem, that could partly be solved with a transaction for all operations of one single version step.
But this will work only for database tables, that are updated from MyISAM to InnoDB and for operations within one version step. When updating a forum (in example) from version 2.4.22 to 20220803.1 (2.5.4) the script currently performs six version-step-operation-blocks. Even when the first four blocks succeeded, so that the database is in the state of an intermediate version (currently this would be the state of version 20220529.1) and one operation in the middle of the fifth block failed, the old version number (in this example 2.4.22) would remain in its database entry.
IMHO we have to rethink the whole process. With version 2.4.99.2 we altered all database tables to the engine InnoDB. So we should be able to unify all database operations of one version step into one transaction and to separate the steps one by one with interim reports for example with task messages like for the necessity to change some users e-mail-address.