Pin version of MariaDB for DB migrations

[sirhcel]

When running database migrations with the latest 10.4.31, they fail as shown in issue #1212. Pinning the point release of MariaDB to the latest known-good version maneuvers around this issue.

[juherr]

This change doesn't fix the issue, it is just hiding it :/

[sirhcel]

Yes, you are absolutely right. Let me rephrase the title. This PR aims at shipping a configuration that just works and might save others the time for troubleshooting.

I would leave tackling the actual issues with the migrations and MariaDB 10.4.31 for others.

[juherr]

Ok. It makes sense. But why not trying to fix the root issue instead?

At least, add a todo comment that explains it is a workaround with a link to the related issue issue.

[slachiewicz]

MariaDB 10.4.31 Docker image was released 4 days ago and it will break environments for everyone pulling fresh 10.4 tags So it's a rational decision to pin to 10.4.30 for the time being.

Release notes:
https://mariadb.com/kb/en/mariadb-10-4-31-release-notes/
https://mariadb.com/kb/en/mariadb-10-4-31-changelog/

[slachiewicz]

MariaDB 10.4.31 Docker image was released 4 days ago and it will break environments for everyone pulling fresh 10.4 tags So it's a rational decision to pin to 10.4.30 for the time being.

Release notes:
https://mariadb.com/kb/en/mariadb-10-4-31-release-notes/
https://mariadb.com/kb/en/mariadb-10-4-31-changelog/

[goekay]

thanks everyone. i agree with the comments here: the PR is not tackling the root cause, but helps to continue providing a working env for builds. this is good enough.

[goekay]

obviously, editing docker-compose is not the whole story. our actions are failing due to the same issue. pls see my branch https://github.com/steve-community/steve/tree/experiment_mariadb and the pinned versions in github workflow. i would appreciate it if you would include them in your PR as well.

[sirhcel]

Thank you very much for all the feedback!

Ok. It makes sense. But why not trying to fix the root issue instead?

Because I have still no idea what's exactly causing this pretty big change in behavior and how to properly deal with it.

Skimming through the changelog for MariaDB 10.4.31, MariaDB/server@5f09b53bdb looks like something which could be related. And for V0_7_7__update.sql the recommended way of dealing with FK checks in this scenario might be disabling them. But in V0_8_6__update.sql, exactly this approach is used and fails.

At least, add a todo comment that explains it is a workaround with a link to the related issue issue.

Done. Also incorporated the additional pinning from @goekay.

[juherr]

If the issue comes from the migration the only solution will be to remove them.

The v1.0 baseline from #1140 can be used to check it.
It will definitively remove the need of extra rights at the same time.

The huge problem is that it will break all existing instances.
But that's just another argument for multiple flavour releases.

@goekay wdyt?

[juherr]

@sirhcel thanks for the todo comment! 🙏