Estoy intentando restaurar desde un servidor reciente a uno creado hoy. Está fallando con este error. No veo eso en ninguna parte del código de Discourse ni en el código del plugin.
No estoy seguro de qué hacer a continuación.
[20/9694]
ERROR: la función discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() no existe
EXCEPTION: psql falló: ERROR: la función discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() no existe
/var/www/discourse/lib/backup_restore/database_restorer.rb:92:in `restore_dump'
/var/www/discourse/lib/backup_restore/database_restorer.rb:26:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:51:in `run'
script/discourse:157:in `restore'
/var/www/discourse/vendor/bundle/ruby/3.
Ohhh, en realidad acabo de encontrar una solución.
Tengo suerte de que el servidor antiguo todavía esté funcionando. Así que reconstruí la aplicación del lanzador para que el servidor antiguo tuviera la misma versión exacta que la nueva instalación. Luego hice otra copia de seguridad a través de la línea de comandos. Al restaurar esta copia de seguridad en la nueva instalación, todo salió bien. Deberías probar esto. @pfaffman
Vaya, me ha pasado lo mismo. Estoy intentando restaurar desde un sistema de producción a un entorno sandbox/desarrollo. También he comprobado que todos los mismos complementos están instalados.
¿Qué otro complemento utiliza esto? Voy a revisar el código fuente ahora mismo…
Asegúrate de que la carpeta /var/discourse/shared estuviera vacía o la moví a una nueva ubicación en caso de que necesitemos restaurarla.
Inicialicé una nueva instancia de Discourse usando ./launcher bootstrap <app>
Intenté la restauración de nuevo y todavía falló con el mismo mensaje de error.
Luego, cuando hice un volcado de mi instancia de Discourse que funcionaba, encontré el comando real que crea la función. Es:
CREATE FUNCTION discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() RETURNS trigger
LANGUAGE plpgsql
AS $$
BEGIN
RAISE EXCEPTION 'Discourse: old_notification_id in chat_mention_notifications is readonly';
END
$$;
ALTER FUNCTION discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() OWNER TO discourse;
¡Luego volví a intentar la restauración y todo salió bien!
Ahora, tenía el registro donde falló y pensé que podría volver a él después, pero los registros se restablecen con cada función de Copia de seguridad/Restauración.
MEJORA: Sería bueno tener un historial de copias de seguridad/restauraciones. Quizás lo haya y no sepa dónde está.
DESCARGO DE RESPONSABILIDAD: No soy una persona de soporte de Discourse, así que no entraré en cómo acceder a la línea de comandos de psql para ejecutar los comandos anteriores. :
El problema es que una migración con una marca de fecha más antigua se incluyó en tests-passed más tarde (@nbianca para tu información), y esto no es detectado por los metadatos de versión en la copia de seguridad. Lo he mencionado aquí.
Esta es la solución. Por lo tanto, necesitas obtener el hash del commit del servidor de la instancia y construir tu nueva instancia con ese commit, o actualizar la instancia existente a la última versión, lo que ejecutará esa migración, y luego hacer una nueva copia de seguridad.
Sí, pero a veces no podrás actualizar la instancia de origen. Y en ese caso, deberás poner el destino en el mismo commit que el origen. Por lo tanto, esta es una excepción a la situación normal en la que siempre puedes hacer una migración implícita hacia adelante durante la restauración.
Voy a probar esto hoy, pero mi suposición actual es que la restauración funciona tan pronto como el sitio de destino está completamente actualizado.
Parece que el problema es que la verificación de versión al principio de la restauración no detecta que la fuente en realidad tenía un esquema de base de datos más nuevo que el destino.
Correcto, y esto sucede porque la migración no tiene la marca de tiempo del momento en que se cometió, sino la marca de tiempo del momento en que se generó. La mayoría de las veces eso no importa, pero en este caso hubo 7 semanas entre esos dos momentos.
Sí, ese es un caso límite desafortunado. Podemos intentar evitarlo en el futuro o intentar encontrar una solución compatible con versiones anteriores para evitar que vuelva a suceder. Sin embargo, no creo que podamos hacer nada para solucionarlo en este caso. Ese barco ya zarpó. Hagamos lo que hagamos, siempre requerirá que los propietarios del sitio actualicen su sitio de destino a la última versión.
Correcto, este es un problema con este tipo de técnicas en general, es un problema genérico para Ruby on Rails y también para otras implementaciones de AR como PHP Laravel. Y como usted dijo, no sucede muy a menudo, y una vez que te das cuenta de lo que está pasando, es fácil de solucionar durante la restauración.
Entonces, en mi escenario, mi entorno de restauración era más nuevo por quizás un par de versiones del seguro que se había copiado. ¿No debería funcionar entonces?
