Estou tentando restaurar de um servidor recente para um criado hoje. Está falhando com este erro. Não vejo isso em nenhum lugar no código do Discourse ou no código do plugin.
Não tenho certeza do que fazer a seguir.
[20/9694]
ERRO: a função discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() não existe
EXCEÇÃO: psql falhou: ERRO: a função discourse_functions.raise_chat_mention_notifications_old_notification_id_readonly() não 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.
Tenho sorte que o servidor antigo ainda está funcionando. Então, fiz a reconstrução do aplicativo no launcher para que o servidor antigo ficasse exatamente na mesma versão da nova instalação. Em seguida, fiz outro backup pela linha de comando. Ao restaurar este backup na nova instalação, tudo correu bem. Você deveria tentar isso. @pfaffman
Eita, eu também já passei por isso. Tentando restaurar de um sistema de produção para sandbox/dev. Eu também verifiquei novamente se todos os mesmos plugins estão instalados.
Qual outro plugin usa isso? Vou verificar o código-fonte agora mesmo…
Verifiquei se a pasta /var/discourse/shared estava vazia ou a movi para um novo local, caso precisemos restaurar.
Inicializei uma nova instância do Discourse usando ./launcher bootstrap <app>
Tentei a restauração novamente e ela falhou com a mesma mensagem de erro.
Então, quando fiz um dump da minha instância boa do Discourse, encontrei o comando real que cria a função. Ele é:
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;
Depois, tentei a restauração novamente, e tudo correu bem!
Agora, eu tinha o log onde falhou e pensei que poderia voltar a ele depois, mas os logs são redefinidos a cada recurso de Backup/Restauração.
MELHORIA: Seria bom ter um histórico de backups/restaurações. Talvez exista um, e eu não sei onde ele está.
AVISO LEGAL: Eu não sou uma pessoa de suporte do Discourse, então não vou entrar em detalhes sobre como acessar o prompt de comando psql para executar os comandos acima. :
Esta é a solução. Portanto, você precisará obter o hash do commit do servidor da instância e construir sua nova instância com esse commit, ou atualizar a instância existente para a versão mais recente, que executará essa migração, e então fazer um novo backup.
Sim, mas às vezes você não conseguirá atualizar a instância de origem. E nesse caso, você precisará colocar o destino no mesmo commit da origem. Portanto, esta é uma exceção à situação regular em que você sempre pode fazer uma migração implícita para frente durante a restauração.
Vou testar isso hoje, mas minha suposição atual é que a restauração funciona assim que o site de destino estiver totalmente atualizado.
Parece que o problema é que a verificação de versão no início da restauração não detecta que a origem realmente tinha um esquema de banco de dados mais novo do que o destino.
Correto, e isso está acontecendo porque a migração não tem o timestamp do momento em que foi confirmada, mas o timestamp do momento em que foi gerada. Na maioria das vezes, isso não importa, mas neste caso houve 7 semanas entre esses dois momentos.
Sim, esse é um caso extremo infeliz. Podemos tentar evitá-lo no futuro ou tentar criar uma solução retrocompatível para impedir que isso aconteça novamente. No entanto, acho que não podemos fazer nada para consertar isso neste caso. O barco já partiu. O que quer que façamos, sempre exigirá que os proprietários do site atualizem seu site de destino para a versão mais recente.
Correto, este é um problema com esse tipo de técnica em geral, é um problema genérico para Ruby on Rails e também para outras implementações de AR como PHP Laravel. E como você disse, não acontece com muita frequência, e uma vez que você percebe o que está acontecendo, é fácil contornar durante a restauração.
Então, no meu cenário, meu ambiente de restauração era mais novo em talvez algumas versões do seguro que foi copiado. Isso não deveria funcionar então?
