Hello

As noted in the previous post, our current forum is 2.4.24, so this one was a 2-step upgrade to get to 20240308.1.

I made a copy of the site and removed any duplicate user emails before proceeding, as I believe the upgrade to 20220803.1 would crash otherwise.

The script itself would not crash in the actual meaning but you would end with a broken forum. So yes, that was a sensible precautionary measure.

I then performed a successful upgrade to 20220803.1
I then performed a successful upgrade to 20240308.1, using the code located in GitHub/master.

Nice.

Some Notes:
1) This script did not crash on the same CREATE TABLE step as the direct upgrade from 2.4.24. I am guessing this is because the b8_rating_table was already created during the upgrade to 20220803.1, but I do see several DROP TABLE commands prior to the CREATE TABLE in Lines 290-294. The comment on the DROP TABLE commands says it was for pre-release testing. Since Im not exactly sure if these lines (290-294) are working as designed, I'm just making a note to you.

Ok, I see there is room for clarifications.

Until version 20220803.1 the upgrade script worked this way: All upgrade steps are additions to previously performed steps (inside a script run). All steps, that names the starting version in its if-clause, get executed one after the other.

Due to errors in the compilation of the necessary changes (namely the uniqueness of the e-mail-addresses in the accounts, to big indexes in case of MySQL < 5.7.7 (or MariaDB < 10.2.2), sizes of specific columns and double indices) it was not possible for me to adapt the necessary changes and fixes to the correct version steps. I lost the track in the end and decided to reorganíse the upgrade script.

Now the upgrade script works by providing a complete upgrade process for every starting version (or groups of versions with an identical database structure). This includes all steps from the changes in the table structure (new, changed or removed columns, new tables) to new, changed or deleted values in table rows.

Additionally – and here we are at the deleting and recreation of the new tables – we got a few reports about broken upgrades because people once upgraded to one of the accessible testing versions (2.4.99.1, 2.4.99.3) but downgraded their forum to a stable version of the 2.4-branch (up to version 2.4.24) again. This resulted in a database structure with the matching tables for 2.4.x but also with the not deleted tables from the testing versions (2.4.99.1, 2.4.99.3). When upgrading now from 2.4.x to a version of the 2.5-branch, the upgrade script failes to create the new but already existing tables.

Because of this the script deletes any existing tables that it is supposed to create and creates them again afterwards when we can be sure, that the database is cleaned up. This step is only necessary, when it comes to an upgrade starting with a stable vesion of the 2.4-branch (2.4.19 to 2.4.24). All other versions, that are allowed to be upgraded with this script, already contain the tables in question, so there is no CREATE statement for one of these tables in these cases.

2) In your original comments, you note that this upgrade doesn't include any much discussed database performance fixes. Our site DB is quite large (~500,000 posts), and runs very slowly on any 2.5 version of MLF due to the performance of some read queries which JOIN on the new Spam tables. I had previously dug into improving performance for our site when running 20220803.1, but never did come up with an acceptable solution. I am willing to look into this further if appropriate, and also wanted to see if you know of any potential improvements that I could test out on our site running 20220803.1 or 20240308.1.

I re-read the old thread about this big issue a few days ago but also did not came to a good, solid solution until now.

Tschö, Auge