MySQL Datenbank-Kollation utf8mb4 versus utf8 in Joomla 3.5

In Joomla 3.5 werden neue Datenbankkollationen eingeführt. Fast alle Core-Tabellen wechseln zu utf8mb4_* statt bisher utf8_*.

Soweit so gut.

Aber MySQL Abfragen mit JOINS auf Core-Tabellen z.B. aus einer eigenen Komponente können jetzt uU Fehler erzeugen, wenn die eigenen Datenbanktabellen noch utf8_* verwenden.

Auf ersten Blick auch kein Problem. Schreibt man halt die Kollation für eigene Erweiterungen ebenfalls um. (Hoffe, das geht so einfach wie ich mir das vorstelle?)

ABER, und da blick ich jetzt nicht mehr durch. utf8mb4_* wird seit MySQL Server-Version 5.5.3 unterstützt, wenn ich richtig verstehe.
Joomla gibt als Voraussetzung für Joomla 3 minimal MySQL Server-Version 5.1 + an.

Muss jetzt jeder Popelprogrammierer, als was ich mich auch sehe, vor Updates, die die Datenbank betreffen auch noch irgendwelche, komplexeren Prüfungen der DB-fähigkeiten ausführen bevor man sein Installer-/Update-SQL "drüberbügelt"?

Vielleicht kennt sich jemand besser aus und kann paar grundlegende Hinweise geben, auch, weil ich einige 3rd-Erweiterungen beim Schritt auf 3.5 schon "explodieren sehe" und selbst gar keinen rechten Plan habe.

Danke!

Nachdem ich bisschen rumprobiert habe, im MySQL-Manual was von "kompatibel"steht, und dann auf Github noch das gefunden habe (bin nicht allein, scheint's)
https://github.com/joomla/joomla-cms/issues/9423
scheints wohl eher um den Wechsel von _general_ci auf _unicode_ci zu gehen, was die Fehler angeht.

Trotzdem blick ich noch nicht wirklich, wie man jetzt wann wie vorgehen sollte. Mein schnelles, plumpes ALTER-Script hat erst mal meine Testseite geschrottet. Von WordPress abgekupfert https://github.com/WordPress/W…ncludes/upgrade.php#L1959
(function maybe_convert_table_to_utf8mb4)

Weiß auch nicht, ob man die Indices ändern MUSS(!) oder nur besser sollte.

Danke. Ja, werd ich machen. Bin schon kirre vom Updaten und Mitlesen
Hab halt kein MySql 5.1 zum Testen. Ignorier ich also plump weg.

Hab auch bei Kunena auf GitHub ein Prozedere gefunden wie man 3rd-Tabellen anpassen kann. (Find den PR grad leider nicht mehr). Die setzten die Indices auch auf Grö0e 191 runter. Werd ich dann auch so machen. Denke mal, das hat positiven Effekt auf reservierte Speichergröße für die Felder.

Umgeschrieben muss nur dann, wenn die Erweiterungen MySql-Querabfragen machen von Tabellen zu Tabellen bzw. genauer: Tabellenfeldern, bei denen die Kollation (Collation) nicht übereinstimmt, besser: wo sie nicht kompatibel ist UND es zu SQL-Fehlermeldungen kommt.
Also bei den JOINs.

Das kommt nicht häufig vor, dass nicht kompatibel, aber kann passieren.

In den allermeisten Fällen kann man also unbesorgt sein und alles wird funktionieren wie zuvor.

Beachten sollte man halt, dass nun auch mehr und mehr 3rd-Erweiterungen umstellen werden. Eigene Erweiterungen, wie Plugins, Module etc., die ihre Daten aus diesen oder mehreren beziehen (zusammenführen), könnten also irgendwann mal betroffen sein.

Bis hier: Soweit ich bisher durchblicke. Muss sich bei mir auch erst mal alles setzen, bevor ich da anfange. Außer eine Fehlermeldung schlägt auf.

(In den 3.5 Beta und RC installiere ich viele 3.4-Erweiterungen querbeet. Aufgefallen ist mir bisher nichts außer bei einer eigenen, die sowieso Pillepalle ist.)

Nachtrag. Hier scheint sich eine Lösung für meine Frage oben zu ergeben

Zitat

Muss jetzt jeder programmierer vor Updates, die die Datenbank betreffen auch noch irgendwelche, komplexeren Prüfungen der DB-fähigkeiten ausführen bevor man sein Installer-/Update-SQL "drüberbügelt"?

Wenn sich der PR durchsetzt, übernimmt Joomla bei Installation/Updates die Prüfung auf utfmb4-tauglichkeit. Man kann seiner eigenen Erweiterung für Install / Updates SQL-Scripte beilegen, welche für utf8 und welche für utf8mb4, die dann entsprechend gezogen werden.
Ob das noch in 3.5.0 Einzug finden wird, ist allerdings unklar. Weil ja eigentlich schon "geschlossen"; außer Bugfixing.

https://github.com/joomla/joomla-cms/pull/9468