Como posso editar diretamente o banco de dados do Discourse a partir de uma GUI?

Estou procurando uma ferramenta amigável para usuários que possa executar consultas SQL e organizar globalmente meu banco de dados atual, contendo posts e usuários importados de dois fóruns mais antigos — por exemplo, excluir tópicos, adicionar certas tags a todos os posts que contenham uma determinada string no título, excluir usuários ou alterar acessos quando os perfis dos usuários não atendem a certos critérios, etc.

Existe algo como o phpMyAdmin que possa editar um backup SQL de administrador do Discourse? Ou até mesmo funcionar com uma instância ao vivo do Discourse?

Vejo que há um plugin que permite consultas dentro do Discourse, mas parece que ele não permite alterações nos dados.

Fazer o download de um backup (sem uploads) e restaurá-lo em uma instância local do PostgreSQL, que você pode consultar com o pgAdmin3, é a melhor opção.

Sim, o plug-in Data Explorer não permite que alterações sejam feitas. Mas sugiro começar com ele mesmo assim. Você pode executar consultas para identificar se há problemas e, em seguida, executar consultas para selecionar os registros que precisam ser alterados. Assim, você estará protegido contra danos acidentais ao seu banco de dados.

Estou assumindo que você já está rodando em produção. Por isso, eu teria muita cautela em modificar o banco de dados sem algum tipo de aprovação da equipe do Discourse.

Uma vez que você esteja familiarizado com o banco de dados do Discourse e saiba o tamanho do problema, poderá considerar suas opções para fazer as alterações. Você pode descobrir que consegue fazer tudo pelo próprio Discourse. Ou talvez tenha tão poucas alterações que a linha de comando seja suficiente.

Obrigado, Falco!

Sou um grande iniciante no uso de qualquer coisa que não envolva apenas clicar com o mouse.

No entanto, consegui configurar uma instância local do Discourse (no Windows 10) seguindo os guias oficiais (sem entender muita coisa), então presumo que em algum lugar deve haver orientação sobre como instalar o pgAdmin3 no mesmo local.

Pergunta bobinha, mas essa instância offline do Discourse é o local onde devo restaurar o arquivo SQL exportado (ou existe outra maneira de ‘restaurar’ um arquivo de backup do banco de dados do Discourse no PostgreSQL)?
E como posso consultá-lo após a restauração? Ou seja, onde e como aponto o pgAdmin3 para o banco de dados em uma instância do Discourse em execução? Onde fica fisicamente o banco de dados de uma instância do Discourse em execução? O fato de a instância do Discourse estar em execução bloqueia o banco de dados de alguma forma?
Não consigo ver nenhum arquivo que corresponda claramente a um banco de dados entre os arquivos do meu servidor local ~ /var/discourse

Obrigado, Remah.

Estou hospedando o Discourse por conta própria, então não tenho acesso à equipe do Discourse.
Estou configurando e executando um fórum para uma pequena comunidade, totalmente de forma voluntária (ou seja, sem orçamento), e estou importando dados de fóruns do MyBB e do Yahoo Groups. Este último, por exemplo, trouxe uma série de notificações por e-mail automáticas e antigas de administração como tópicos no Discourse, que são bastante irrelevantes neste contexto.

É provável que eu precise testar e fazer alterações globais de forma esporádica e incremental, à medida que descubro novos problemas — daí o desejo de minimizar a curva de aprendizado e qualquer coisa baseada em CLI!

Vi seu nome de domínio e visitei seu site pela primeira vez, então entendo um pouco sua situação. Estou em Wellington, por acaso, configurando e usando ativamente alguns fóruns privados para instituições de caridade.

Dado seu tempo e experiência limitados, sugiro começar com as ferramentas mais simples e fáceis de usar, avançando para o próximo nível apenas se for necessário. Dominar algo além do primeiro nível — que é simplesmente usar o próprio Discourse — tem um custo elevado. Quando usado conforme projetado, ele pode ser incrivelmente poderoso.

  1. A interface gráfica do Discourse com os recursos que você precisará dominar de qualquer forma.

    • Familiarize-se com o que precisa usar no Discourse. Você pode descobrir que consegue fazer 99% do necessário sem precisar ir além. Portanto, talvez nem precise avançar.

    • Priorize problemas reais e visíveis.
      Por exemplo, suas notificações por e-mail antigas podem não ser um grande problema. Se forem irrelevantes, elas, conforme projetado, perderão destaque no Discourse à medida que tópicos mais relevantes forem criados. O mais importante é colocar seu fórum em funcionamento corretamente do que resolver todos os erros de dados.
      Então, quantas dessas notificações automáticas por e-mail foram convertidas em tópicos?

  2. O plug-in Data Explorer será útil para você, sendo o próximo passo para uma melhor compreensão do banco de dados e para identificar o que pode precisar ser feito. Mais tarde, ele ajudará na geração de relatórios, mas não é absolutamente necessário.

    • A impossibilidade de fazer alterações funciona como uma rede de segurança, pois há alguns anos muitos usuários danificavam seus dados com atualizações precipitadas.

    • As consultas que você gera para identificar registros problemáticos estão apenas um passo de distância de comandos SQL para modificar o banco de dados.

  3. A última opção provavelmente será o uso da linha de comando e de scripts para modificar seu banco de dados.

    • Prefiro correr o risco de exibir dados ruins do que arriscar danificar o banco de dados ao modificá-lo manualmente. Isso pode criar uma bomba-relógio, pois algumas corrupções de dados podem não ser identificadas a tempo.

    • Usar o Data Explorer fornecerá resultados de consulta com exemplos reais de dados e números quantificáveis de registros. É mais provável que você obtenha uma resposta correta da equipe e de outros especialistas se eles puderem entender seus dados e o que você está tentando alcançar. Assim, eles poderão orientá-lo sobre a maneira mais simples e segura de atualizar o banco de dados.

    • Grande parte do que você precisa provavelmente já está em tópicos existentes, pois outros sites enfrentam problemas semelhantes. Portanto, você estará apenas copiando o conhecimento difícil de outros.

Isso. Simplesmente não modifique o banco de dados diretamente. Você vai se arrepender disso um dia.

Obrigado, Remah.

Tudo parece um conselho sensato.
Talvez eu possa obter uma solução parcial por meio de crowdsourcing, se conseguir convencer alguns usuários a procurar e marcar manualmente tópicos para exclusão.

No momento, o site no domínio é essencialmente um placeholder de tela limpa, enquanto um freelancer está ajustando o processo de importação dos fóruns antigos (ajustando o script de importação para o MyBB em particular, para que, esperamos, os campos de perfil de usuário personalizados que configurei lá sejam importados junto com os usuários e suas postagens. Também esperamos que o MyCode em algumas postagens do MyBB seja analisado corretamente (no momento, os códigos de formatação estão visíveis).

Perdi uma semana tentando fazer essa importação sem sucesso, mas não consegui configurar um ambiente de desenvolvimento com todos os pré-requisitos necessários para fazê-lo, nem em uma instância do Ubuntu no Windows 10, nem em uma instância baseada na DigitalOcean, seguindo o guia oficial para uso do script de importação do MyBB.

Depois de lutar dolorosamente, resolvendo uma mensagem de erro após a outra, finalmente esbarrei em um muro absoluto em ambos os casos ao tentar tornar o banco de dados SQL acessível ao executar o comando final do Ruby on Rails que iniciaria a importação.

Linux e Ruby parecem ter sido escritos por sádicos para masoquistas, sendo ambos notavelmente frágeis e arcanos. Nesse tipo de ambiente, as chances de problemas catastróficos ao manipular bancos de dados parecem realmente altas!

Tenho a minha simpatia.

Mantenha-se como administrador do fórum. :+1:

A facilidade de uso sempre foi deficiente nesse ambiente. Acredito que a linha de comando é ainda mais rainha do que era há 20 anos.

Mas é por isso que gosto do Discourse. A equipe se esforça para tornar o Discourse principal significativamente mais amigável. Infelizmente, migrar é uma opção de alta tecnologia.

É quase certo que seja melhor fazer isso pelo console do Rails.

Acho que isso pode depender do seu critério para ‘melhor’.
No meu caso, sendo iniciante, a curva de aprendizado mais baixa possível e a complexidade mínima de acesso para quem normalmente não tem um ambiente de desenvolvimento configurado e não sabe nada sobre Ruby (ou de fato Linux) seriam prioridades altas. Seria diferente se eu tivesse algum outro motivo (e tempo) para me atualizar sobre essas coisas… Em um mundo perfeito, haveria algum tipo de aplicativo local com GUI para Windows que pudesse consultar diretamente minha configuração do Discourse hospedada na Digital Ocean…

Se você decidir não fazer as alterações diretamente no banco de dados, pode achar úteis alguns dos comandos descritos neste tópico: Administrative Bulk Operations. Por exemplo, ele fornece detalhes sobre como marcar tópicos a partir do console do Rails. O mais importante é fazer um backup do banco de dados do seu site antes de executar qualquer comando.

Meu critério para “Melhor” é “muito menos propenso a deixar seu banco de dados em um estado quebrado e completamente inutilizado.” Como você é um “iniciante”, não sabe quais tabelas precisam ser atualizadas quando você faz . . . alguma coisa.

Seja como for que você faça, certifique-se de fazer backups frequentes.

Um ponto válido — tentarei encontrar outras maneiras em primeira instância.
Minha ignorância representa um grande risco em ambos os cenários, mas é correto afirmar que realizar alterações no banco de dados via Ruby será mais seguro do que tentar as mesmas alterações usando o pgAdmin4?

O risco de causar danos que não sejam imediatamente percebidos já foi mencionado, por exemplo — há algo em uma abordagem versus a outra que possa influenciar esse risco?

No fundo da minha mente, caso eu decida correr esse risco (após fazer backups adequados), imaginei uma cópia do pgAdmin4 rodando no meu droplet da Digital Ocean, a qual eu pudesse acessar diretamente via URL no navegador, em vez de usar janelas de console CLI, eliminando assim algumas camadas de complexidade (assumindo aqui que isso seja até mesmo possível).

Basicamente, sim. O Ruby faz várias coisas mágicas para garantir que a coisa certa aconteça. Por exemplo, se você destruir (excluir) algo de um modelo, ele sabe quando e quais outras coisas devem ser excluídas. Há muitas coisas “seguras” que você pode fazer com SQL puro, mas eu quase sempre faço isso no Rails, se for possível.

Ah, isso é bom de saber — obrigado!

Isso parece potencialmente muito útil — obrigado!

Como resolvi a questão Como posso editar diretamente o banco de dados do Discourse a partir de uma GUI?, já que a resposta não atendia ao que eu buscava.

:warning: Não faça isso em uma máquina de produção.

Este método utiliza a ferramenta de administração recomendada para PostgreSQL, o pgAdmin 4.

Isso foi feito na minha máquina local para aprender mais sobre o Discourse, por exemplo: instalar, configurar, ajustar, desenvolver plugins, usar a API e webhooks, etc.

Nota: O Discourse foi instalado no Ubuntu 18.04, via WSL 2 no Windows 10, seguindo o Guia para Iniciantes para Instalar o Discourse no Windows 10 para Desenvolvimento.

Nota: O WSL 2 não vem com systemd. Problema 457.

Utilizando o guia Instalar o pgAdmin 4 no Ubuntu 20.04/18.04/16.04 como modelo.

Usando BASH

$ echo "deb http://apt.postgresql.org/pub/repos/apt/ `lsb_release -cs`-pgdg main" |sudo tee  /etc/apt/sources.list.d/pgdg.list
deb http://apt.postgresql.org/pub/repos/apt/ bionic-pgdg main
$ sudo apt update
$ sudo apt install pgadmin4 pgadmin4-apache2

E-mail do usuário pgAdmin4: postgres@localhost
Senha do pgAdmin4: <senha 1>

$ sudo /etc/init.d/apache2 restart
$ sudo ufw allow http
$ sudo ufw allow https
$ hostname -I

Registre o <endereço>

$ whoami

Registre o <nome de usuário>

Esta próxima etapa pode não ser necessária, pois eu não sabia como obter a senha de um usuário do banco de dados Postgres, já que não sou especialista em PostgreSQL, ou se havia outra maneira de configurar o login no banco de dados necessário para o pgadmin4.

$ psql postgres

Usando PSQL

postgres=# ALTER ROLE <nome de usuário> '<senha 2>';  

Usando um navegador de internet

http://<endereço>/pgadmin4

usuário: postgres@localhost
senha: <senha 1>

Uma vez iniciado o pgAdmin4

Usando o pgAdmin4

Criar uma conexão com o servidor

Aba: Geral
   Nome: Discourse Development
   Grupo de servidores: Servers
Aba: Conexão
   Host: localhost
   Porta: 5432
   Banco de dados de manutenção: postgres
   Nome de usuário: <nome de usuário>
   Senha: <senha 2>

Isso não é perfeito, mas funciona e é melhor do que nada. Feedback e sugestões são bem-vindos.


Bônus

PostgreSQL
Catálogo de Software - Ferramentas de administração/desenvolvimento

Eu acho que, para a maioria das ações, é mais fácil e um pouco mais seguro acessar o console do Rails do que interagir diretamente com o banco de dados.

Ou, se o que você quer fazer é alterar a senha de um usuário (oh, não era isso que você tentava fazer, mas isso ainda é um bom exemplo), faça:

cd /var/discourse
./launcher enter app
rake admin:create

Apesar do nome, essa tarefa rake permitirá que você:

  • crie um usuário (mas não há problema se o usuário já existir)
  • altere a senha (mas não é obrigatório)
  • torne o usuário um administrador (mas não é obrigatório).

Dê uma olhada em Operações em Massa Administrativas para alguns outros exemplos.

Mas aqui estão alguns:

users=User.all
me=User.find_by_username ('pfaffman')
me=User.find_by_email('jay@literatecomputing.com')
UserEmail.create!(user: me, email: 'myotheraddress@somewhereelse.com')
posts_with_uploads=Post.where("raw like '%upload%' ")
Group.create(
  name: "mygreatgroup",
  automatic_membership_email_domains: 'literatecomputing.com',
  primary_group: true,
  title: "Equipe Literate Computing",
  grant_trust_level: 4,
  flair_url: 'https://example.com/path.icon.png'
)

Obrigado pelo feedback. Mais uma coisa para eu aprender.

Embora eu tenha décadas de experiência em desenvolvimento, nunca usei Ruby ou Rails. Na verdade, comecei a programar com cartões perfurados na faculdade e, pessoalmente, com um Atari 800.