Explicitly set InnoDB, utf8mb4, and 0900 collation

[nakrovati]

BREAKING CHANGE: The syncserver now strictly requires MySQL 8.0+ or MariaDB 11.4.5+ / 11.7+ (due to the use of utf8mb4_0900_ai_ci collation as an alias to utf8mb4_uca1400_nopad_ai_ci). Older versions are no longer compatible.

[istudyatuni]

or manually altered

Why not to do ALTER in a new migration instead of breaking existing?

[nakrovati]

or manually altered

Why not to do ALTER in a new migration instead of breaking existing?

1. To ensure that everyone has the same settings by default;
2. To ensure that table settings are clearly visible when reading the code;
3. To prevent possible errors in the future when working on new versions of MariaDB/MySQL when converting from future new values ​​of ENGINE, CHARSET and COLLATE (in the next versions of MySQL/MariaDB) to those that we use by default (InnoDB, utf8mb4, utf8mb4_0900_ai_ci);
4. To avoid creating an unnecessary migration;
5. To limit project support to only new versions of MariaDB/MySQL.

So, in order of importance in my opinion: 3,1,2,4,5

[istudyatuni]

To ensure that everyone has the same settings by default

But for already existing servers this won't be applied even after updating

To avoid creating an unnecessary migration

But that's the reason to use migrations - to migrate existing databases

[nakrovati]

To ensure that everyone has the same settings by default

But for already existing servers this won't be applied even after updating

To avoid creating an unnecessary migration

But that's the reason to use migrations - to migrate existing databases

But for already existing servers this won't be applied even after updating

Smoothly - yes, but users can bump the database, recreate it, and transfer data from the dump - the table structure has not changed. And after recreating the database, they can simply synchronize data from the application.

But that's the reason to use migrations - to migrate existing databases

Yes, but when converting ENGINE, CHARSET, and COLLATE, and since synchronization is still considered experimental and not many people have hosted the server themselves (as far as I know), it is better to remove them now and unify them immediately for all users and for both DBMSs than to later help each user correct conversion errors for these settings. And anyone who deployed their databases on older versions of the DBMS within two months (the commit with migrations was made on July 30) will have to help.

[istudyatuni]

but users can bump the database, recreate it, and transfer data from the dump

I guess people will just ignore it :(

[nakrovati]

@Koitharu, maybe it's better to remove the migration formatting revert (from the previous commit)? It's been two weeks already, a bit too late to "quickly" undo it.