Hello

Like probably most other users, I only read here occasionally. I therefore apologize for only seeing the notice now.

You don't have to apologise. I was really disappointed by those who had just asked us for a solution to the new EU Digital Services Act legislation and who I assumed would help us with testing in the interest of a quick new release. I didn't made that clear enough in my "ranting" posting.

I'm running 2.4.20 with about 600.000 posts.
I tried update/update_2.4.19-2.5.php. I downloaded it today from github.

Result:
I experienced the same issues as Joe I. So the update process is at least consistent over different systems. ;)

Running the upgrade script from any version within the range from 2.4.19 to 2.4.24 runs the same section of the script. Consequently, the same errors occur. That's consistency.

The update ran for 5 min, which may be relevant for admins who set a time out for running php scripts.

Wow, five minutes! In my testing instance, a copy of my forum for testing my theme with only nearly 100 postings, the upgrade ran within around a second. That the running time will be longer with more than a half million entries sounds reasonable, but five minutes!

@Joe: What's your experience with running time of the script?

Do we need mentions, perhaps? 🤔

After 5 min, the following error occurs:
Database error in line 298: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ' KEY `b8_spam` (`spam`), KEY `B8_training_type` (`training_type`)) ENGINE=Inn...' at line 1

That's the same error like Joe reported. Also he, like you, startet with a stable version of the 2.4-branch. I have a pull request in the pipeline, that solves also this bug.

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.

My solution a few months ago was to manually remove all joins with spam tables, since I don't need the spam detection functions. But it was still slow and it's surely not the best solution to fork every release.

It's an option to customise the queries based on the settings to prevent unnecessary joins. In your case it seems to be the solution because there is really no need to join unused tables. There are further cases of table joins, that are always executed, but which, strictly speaking, are settings-dependent.

But on the other hand alls this solves nothing for installations, where the spam prevention mechanisms or specific other settings are in use. And it makes the decision making tree in the code much more complex.

If I can help in any way, please let me know!

I think we really need thoughtful input from as many sides as possible. And we need more testing of changes in the database structue. Not only in this case but also in the future.

Thank you for your input.

Tschö, Auge