johnnyq
|
2c9bd0a7f2
|
Let the database update get past 3.2.8 on installs whose tables have different collations, and on ones already stuck there: 3.2.8 matched license names against template names across software and software_templates, the second being one of the tables 2.1.6 to 2.4.1 created without a COLLATE, so where the server default is not utf8mb4_general_ci, MariaDB 11.5 and later, the comparison failed with Illegal mix of collations after the two ALTERs above it had gone in, and every run after that stopped at the first of them with Duplicate column name software_template_id, short of 3.6.5 which puts those tables right; admin/database_updates.php now runs databaseCollationRepair before each update it applies as well as after the last, so no update meets two collations whatever version it starts from, loads functions/database_collation.php itself when the process started on code from before it, and does not try a table again in the same run once it has failed, databaseCollationRepair taking a list of tables to skip; 3.2.8.php is changed in what it can get through and not in what it makes, each ALTER checked first so it can run again from wherever it stopped, the comparison naming its collation and the UPDATE leaving licenses that already have a template; every update from 2.0.7 to 3.6.5 was run on MariaDB with those 22 tables in utf8mb4_uca1400_ai_ci and 3.2.8 was the only one that failed, then the whole history run through the new runner with the tables put wrong before every update, on an install left as the forum report had it and from a process started on older code; CONTRIBUTING.md records the exception to never editing a shipped migration and the 26.11.7 changelog section has the fix
|
2026-11-11 21:13:02 -05:00 |
|
johnnyq
|
69fd43051f
|
Keep collations at utf8mb4_general_ci going forward: functions.php now ends by calling databaseConnectionCollation, which runs SET collation_connection = 'utf8mb4_general_ci' on the connection config.php opened, so a string the server makes itself, CAST(x AS CHAR) for one, matches the tables where on MySQL 8 it came out utf8mb4_0900_ai_ci and failed beside a column with Illegal mix of collations, on a new install as much as an upgraded one; only the collation is set and not the character set, no SET NAMES and no mysqli_set_charset, because on a server that defaults to latin1 the connection has always been latin1 and changing it shows every accented letter already stored as two wrong ones, where setting collation_connection alone leaves what is stored and what is stored after the same; admin/database_updates.php calls databaseCollationRepair after a run that applied at least one database update and finished, so a table a migration creates without a COLLATE is given the collation db.sql has in the same run, with what it changed and what it could not going to App Logs and to the output of scripts/update_cli.php, a table it cannot change left as it was and never failing the update, and a run that stops at a failed migration leaving this for the run that finishes; run on MySQL 8.0 and MariaDB 10.11, on a latin1 server default and through update_cli.php --update_db with a migration written as 2.4.1 was; CONTRIBUTING.md and the 26.11.7 changelog section say so
|
2026-11-11 20:52:46 -05:00 |
|
johnnyq
|
bce68aac6a
|
Add a collation check and repair to Admin > Debug: functions/database_collation.php reads from db.sql each table's default collation and each text column's, compares them with information_schema and can give every table that differs the collation db.sql has for it, one ALTER a table with a MODIFY a column built from its SHOW CREATE TABLE line with only the collation replaced, as database 3.6.5 does, so a binary column that was flattened goes back to utf8mb4_bin too and no column type changes; the ITFlow section gains a Database collation check that warns when any table differs, and the Database card lists them under Structure a row a table, in Copy for support as well, with a Repair collations button behind a confirm; the button posts to the new admin/post/debug.php, CSRF-checked and not tied to the request so a large table is not cut off with the browser, which writes an audit log entry naming the tables changed and a warning in App Logs for each one it had to leave, a table being changed whole or not at all; tables and columns db.sql does not have are not looked at; run through the page and against the whole schema on MySQL 8.0 and MariaDB 10.11; add both to the 26.11.7 changelog section
|
2026-11-11 20:33:19 -05:00 |
|