Alors oui, cela est généralement dû à des bases de données/tables/schémas mal configurés, mais c'est un nouveau code et je veux m'assurer qu'il fonctionne correctement car je ne suis pas sûr à 100% que ce soit le cas.

C'est en fait un problème UeberDB mais peu importe, tout va bien. La logique ici : https://github.com/ether/ueberDB/blob/master/mysql_db.js#L81

Je vais supposer que votre base de données Etherpad s'appelle etherpad_lite_db . Si ce n'est pas le cas, remplacez comme il convient.

Effectuez les commandes suivantes :

mysql -uroot -p

use etherpad_lite_db

SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME = 'etherpad_lite_db';

Copiez et collez la sortie (ici c'est bien).

Suivant... Copiez/collez la commande finale..

SELECT CCSA.character_set_name FROM information_schema.`TABLES` T,information_schema.`COLLATION_CHARACTER_SET_APPLICABILITY` CCSA WHERE CCSA.collation_name = T.table_collation AND T.table_schema = 'etherpad_lite_db' AND T.table_name = 'store';

Copiez et collez la sortie.

Vos deux sorties doivent être

| DEFAULT_CHARACTER_SET_NAME | DEFAULT_COLLATION_NAME |
+----------------------------+------------------------+
| utf8mb4                    | utf8mb4_general_ci     |
+----------------------------+------------------------+

et

| character_set_name |
+--------------------+
| utf8mb4            |
+--------------------+

Si ce n'est pas le cas, votre base de données n'a pas été correctement configurée et certains caractères vont _potentiellement_ casser certains pads de votre instance. Si vous voyez du latin là-dedans, vous êtes foutu et vous devrez exécuter ces commandes (je pense [non testé]) ...

ALTER DATABASE `etherpad_lite_db` CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

et

ALTER TABLE `store` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

S'ils ne fonctionnent pas, faites-le moi savoir.

Voici le résultat de la première commande :

| DEFAULT_CHARACTER_SET_NAME | DEFAULT_COLLATION_NAME |
+----------------------------+------------------------+
| utf8mb4                    | utf8mb4_general_ci     |
+----------------------------+------------------------+

Tel était ton souhait

Et c'est pour le deuxième...

| character_set_name |
+--------------------+
| utf8               |
+--------------------+

Oups…
Que puis-je faire maintenant ?

désolé, je suis allé un peu vite sans voir la fin du message, je vais tester la modification de la base de données maintenant.

Super! Ça a marché.
Plus de messages dans les logs

Gagner. C'est super de voir mon travail / mes efforts validés alors merci mec ! :)

Merci pour ces commandes ! Un de mes serveurs avait "latin1" ici.

Cependant, je n'ai certainement jamais dit à etherpad d'utiliser latin1, pourquoi etherpad n'est-il pas en mesure de configurer correctement sa base de données elle-même? Est-ce que chaque administrateur doit configurer manuellement le jeu de caractères de chaque base de données ?

Merci pour ces commandes ! Un de mes serveurs avait "latin1" ici.

Cependant, je n'ai certainement jamais dit à etherpad d'utiliser latin1, pourquoi etherpad n'est-il pas en mesure de configurer correctement sa base de données elle-même? Est-ce que chaque administrateur doit configurer manuellement le jeu de caractères de chaque base de données ?

1. latin1 est la valeur par défaut dans MySQL, toujours, en 2020. Cela n'a rien à voir avec Etherpad !
2. Etherpad est correctement capable de configurer la base de données elle-même, mais nous avons choisi de ne pas le faire car nous ne voulons pas forcer utf8mb4 et al sur les administrateurs, car les administrateurs peuvent préférer un autre jeu de caractères. Nous ne sommes pas des DBA.
3. Les administrateurs doivent créer la base de données, donc oui, lorsque vous créez la base de données, vous copiez/collez la commande alter. Ceci est uniquement pour MySQL, si vous utilisez une autre base de données, ce n'est pas un problème. Nous ne pouvons pas gérer chaque cas limite de chaque déploiement dans chaque instance. Il y a une limite à la portée de notre travail (qui consiste à construire un éditeur collaboratif)
4. Etherpad n'est pas responsable ici, UeberDB l'est. C'est juste que ce problème est là parce qu'Etherpad est le plus gros utilisateur d'UeberDB. Nous sommes en train de moderniser UeberDB et cet avertissement était la première étape. Nous ne pouvons pas forcer un changement à cause du point #2

Je pense que notre approche ici était équilibrée et juste, mais je peux comprendre si vous vous sentez un peu frustré que ce ne soit pas du click and go ! <3

Etherpad est correctement capable de configurer la base de données elle-même, mais nous avons choisi de ne pas le faire car nous ne voulons pas forcer utf8mb4 et al sur les administrateurs, car les administrateurs peuvent préférer un autre jeu de caractères. Nous ne sommes pas des DBA.

Je suis l'administrateur, mais je ne pense pas pouvoir décider avec quel jeu de caractères une application s'exécute. Est-il même logique de me laisser ce choix ? Je m'attendrais à ce que le mauvais choix ne fasse que casser l'application. Je ne décide pas non plus du jeu de caractères des requêtes/réponses HTTP, ni du jeu de caractères des fichiers stockés dans le système de fichiers.

Ainsi, il me semble plutôt étrange qu'il appartienne à l'administrateur de décider des détails internes d'une application, tels que le jeu de caractères utilisé pour la base de données. Vous ne me laissez pas non plus le schéma de la base de données. ;)

latin1 est la valeur par défaut dans MySQL, toujours, en 2020. Cela n'a rien à voir avec Etherpad !

Oh je vois. Eh bien, c'est... triste, je suppose ? On dirait que tout le monde a résolu le problème du jeu de caractères ces jours-ci en passant à utf8, à l'exception de mysql... :(

Donc, pour l'instant, la réponse semble être "oui, les administrateurs sont censés configurer cela eux-mêmes". Je me rends compte que c'est la situation dans l'écosystème mysql et non votre action, je voulais juste donner quelques commentaires du point de vue d'un utilisateur. Avoir une erreur à ce sujet dans les journaux est un bon début, mais je n'analyse pas non plus les journaux régulièrement à la recherche d'erreurs, il y a tout simplement trop de choses dans les journaux.

Peut-être qu'une solution possible serait qu'Etherpad modifie la base de données comme il convient par défaut, mais qu'il dispose d'une option de configuration pour la désactiver au cas où les administrateurs de base de données souhaiteraient faire un choix différent ? Cela éviterait le pistolet - ce n'est que par pur hasard que j'ai même vu ce problème, d'habitude je n'aurais jamais remarqué. Je suis peut-être naïf, mais je m'attends à ce que le nombre d'administrateurs qui souhaitent outrepasser ce choix soit minime.

Enregistré avec remerciements :)