Bonsoir,
nous avons découvert tardivement un comportement apparu dans les builds P22 postérieurs à fin février… Simplicité® version 4.0 patch level P22 (database patch level P22), built on 2019-03-22 16:56 (revision 5cf1412916971b88e4cbab66e5127ec3a36d1fd6) for tomcat 8, encoding UTF-8 (system encoding UTF-8) OS : Linux amd64 3.10.0-957.5.1.el7.x86_64, Server : Apache Tomcat/9.0.17 of type WEB run by user root, Database MySQL 5.5.45-log using BLOBs
En effet, nous avons dans notre configuration un objet SELECT dont la requête constitue des agrégats d’information de diverses sources (champs d’objets). Le code SQL (dont l’indécence interdit toute publication intégrale) est composé de divers SELECT agrégés par UNION dont certaines colonnes résultent de recherches de traductions (de noms d’objets ou de textes statiques), de concaténations de groupes (GROUP_CONCAT) pouvant nécessiter de redéfinir la COLLATION (COLLATE utf8_general_ci) pour contourner une erreur [Illegal mix of collations for operation ‘UNION’]…
Il est certainement possible de supporter le besoin (que je n’ai pas décrit) autrement mais pour l’instant, c’est comme ça que c’est fait (certes, c’est sale).
La question concerne l’erreur “COLLATION ‘utf8_general_ci’ is not valid for CHARACTER SET ‘utf8mb4’” survenant sur notre environnement de DEV déployé sur la base des builds mis à dispotition depuis fin février (nos environnements de test et de production n’ont pas été redéployés depuis début mars; ils sont toujours basés sur un build réalisé le 26/02).
Cette erreur disparaît si nous redéployons en DEV le build du 14/02… Simplicité® version 4.0 patch level P22 (database patch level P22), built on 2019-02-14 12:43 (revision 517718ca5fd0699b62f547b9fab494945afbab71) for tomcat 8, encoding UTF-8 (system encoding UTF-8) OS : Linux amd64 3.10.0-957.5.1.el7.x86_64, Server : Apache Tomcat/9.0.16 of type WEB run by user root, Database MySQL 5.5.45-log using BLOBs
L’erreur disparait si l’on remplace COLLATION ‘utf8_general_ci’ par COLLATION ‘utf8mb4_general_ci’…
Quelque-chose a-t-il changé au niveau de l’intégration MySQL depuis fin février? (des paramètres de session? ou autre?)
Les dernières images utilisent désormais un driver JDBC MySQL 8.0.15 (vs un 5.x avant). Cette évolution est liée au besoin de supporter des bases de données MySQL 8.x (version qui n’est pas compatible avec un driver 5.x).
MySQL Connector/J 8.0 is highly recommended for use with MySQL Server 8.0, 5.7, 5.6, and 5.5. Please upgrade to MySQL Connector/J 8.0.
J’avoue ne pas maîtriser du tout les subtilités des collations/charset MySQL (en particulier vs la version du driver JDBC).
Je pense donc qu’il vaudrait mieux chercher dans les forums MySQL pour voir si d’autres personnes rencontrent le même genre de pb. Exemple: Vu dans ce forum mysql check collation of a table - Stack Overflow
What you show is the charset, not the collation. Two tables may have the same charset utf8 , but different collations utf8_general_ci vs utf8_unicode_ci . This can cause error messages like HY000, 1267, Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation '=' … which is the message that brought me to this page
J’imagine que ça doit donc être un pb de collation hétérogène entre les différentes tables du select. Il faudrait savoir ce qu’il en est pour comprendre d’où peut venir cette hétérogénéité…
Nous avons de fait des collations hétérogènes soit par construction (il s’agit d’un rapport de non conformité qui fait de la soupe de légumes) soit du fait de la non spécification de la collation sur certaines colonnes. S’agissant en l’occurrence d’une partie de requête qui va jardiner dans les objets socles (traductions et noms d’objets), j’ai préféré contourner la difficulté en forçant les collations dans la requête globale.
Le changement de driver JDBC semble effectivement être l’explication. Si j’ai bien compris ce que j’ai lu, il s’agit d’une histoire de transition de utf8mb3 vers utf8mb4: