Entonces, sí, esto generalmente se debe a bases de datos / tablas / esquemas mal configurados, pero es un código nuevo y quiero asegurarme de que funcione correctamente porque no estoy 100% seguro de que lo sea.

En realidad, es un problema de UeberDB, pero sea lo que sea, aquí está bien. La lógica aquí: https://github.com/ether/ueberDB/blob/master/mysql_db.js#L81

Voy a suponer que su base de datos Etherpad se llama etherpad_lite_db . Si no es así, reemplácelo según corresponda.

Realice los siguientes comandos:

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';

Copie y pegue la salida (aquí está bien).

Siguiente ... Copie / pegue el comando final ..

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';

Copie y pegue la salida.

Tus dos salidas deben ser

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

y

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

Si no es así, su base de datos no se configuró correctamente y ciertos caracteres _potencialmente_ romperán algunos pads en su instancia. Si ves latín allí, no lo jodiste y tendrás que ejecutar estos comandos (creo que [no probado]) ...

ALTER DATABASE `etherpad_lite_db` CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

y

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

Si no funcionan, déjame saber.

Aquí está el resultado del primer comando:

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

Tal era tu deseo

Y esto es por el segundo ...

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

Vaya ...
Qué puedo hacer ahora ?

lo siento, fui un poco rápido sin ver el final del mensaje, ahora voy a probar la modificación de la base de datos.

¡Excelente! Funcionó.
No más mensajes en los registros

Ganar. Es genial ver mi trabajo / esfuerzos validados, ¡así que gracias hombre! :)

¡Gracias por estos comandos! Uno de mis servidores tenía "latin1" aquí.

Sin embargo, ciertamente nunca le dije a etherpad que usara latin1, ¿por qué etherpad no puede configurar correctamente su base de datos? ¿Se espera que cada administrador tenga que configurar manualmente el juego de caracteres de cada base de datos?

¡Gracias por estos comandos! Uno de mis servidores tenía "latin1" aquí.

Sin embargo, ciertamente nunca le dije a etherpad que usara latin1, ¿por qué etherpad no puede configurar correctamente su base de datos? ¿Se espera que cada administrador tenga que configurar manualmente el juego de caracteres de cada base de datos?

1. latin1 es el valor predeterminado en MySQL, aún así, en 2020. ¡Eso no tiene nada que ver con Etherpad!
2. Etherpad puede configurar correctamente la base de datos en sí, pero decidimos no hacerlo porque no queremos forzar utf8mb4 et al a los administradores, ya que los administradores pueden preferir otro juego de caracteres. No somos administradores de bases de datos.
3. Los administradores tienen que crear la base de datos, así que sí, cuando crea la base de datos, copia / pega el comando alter. Esto es solo para MySQL, si usa otra base de datos no es un problema. No podemos manejar todos los casos extremos de cada implementación en cada instancia. Hay un límite para el alcance de nuestro trabajo (que es construir un editor colaborativo)
4. Etherpad no es responsable aquí, UeberDB sí lo es. Es solo que este problema está aquí porque Etherpad es el mayor usuario de UeberDB. Estamos en el proceso de modernizar UeberDB y esta advertencia fue el primer paso. No podemos forzar un alter por el punto # 2

Creo que nuestro enfoque aquí fue equilibrado y correcto, pero puedo entender si te sientes un poco frustrado porque no es un clic y listo. <3

Etherpad puede configurar correctamente la base de datos en sí, pero decidimos no hacerlo porque no queremos forzar utf8mb4 et al a los administradores, ya que los administradores pueden preferir otro juego de caracteres. No somos administradores de bases de datos.

Soy el administrador, pero no creo que pueda decidir con qué juego de caracteres se ejecuta una aplicación. ¿Tiene sentido dejar esa elección a mí? Esperaría que la elección incorrecta simplemente rompa la aplicación. Tampoco estoy decidiendo sobre el juego de caracteres de la solicitud / respuestas HTTP, o el juego de caracteres de los archivos almacenados en el sistema de archivos.

Por lo tanto, me parece bastante extraño que dependa del administrador decidir los detalles internos de una aplicación, como el juego de caracteres utilizado para la base de datos. Tampoco me está dejando el esquema de la base de datos. ;)

latin1 es el predeterminado en MySQL, aún así, en 2020. ¡Eso no tiene nada que ver con Etherpad!

Oh ya veo. Bueno, eso es ... triste, supongo. Parece que todos resolvieron el problema del juego de caracteres en estos días moviéndose a utf8 excepto mysql ... :(

Entonces, por ahora, la respuesta parece ser "sí, se espera que los administradores configuren esto ellos mismos". Me doy cuenta de que esta es la situación en el ecosistema mysql y no tuya, solo quería dar algunos comentarios desde la perspectiva de un usuario. Tener un error al respecto en los registros es un gran comienzo, pero tampoco escaneo los registros en busca de errores con regularidad, simplemente hay demasiadas cosas en los registros.

Tal vez una posible solución sería que etherpad altere la base de datos según corresponda de forma predeterminada, pero ¿tiene una opción de configuración para desactivarla en caso de que los administradores de bases de datos quieran hacer una elección diferente? Eso evitaría el pistoletazo de salida; es solo por pura casualidad que incluso vi este problema, por lo general, nunca lo habría notado. Tal vez soy ingenuo, pero espero que la cantidad de administradores que quieren anular esa elección sea pequeña.

Notado con agradecimiento :)