Come posso modificare direttamente il database di Discourse da un'interfaccia grafica?

Sto cercando uno strumento user-friendly in grado di eseguire query SQL per ordinare globalmente il mio database attuale, contenente post e utenti importati da due forum più vecchi. Ad esempio, per eliminare argomenti, aggiungere determinati tag a tutti i post che contengono una certa stringa nel titolo, eliminare utenti o modificare gli accessi quando i profili utente non soddisfano determinati criteri, ecc.

Esiste qualcosa di simile a phpMyAdmin che possa modificare un backup SQL di un amministratore di Discourse? O che possa addirittura funzionare con un’istanza live di Discourse?

Vedo che esiste un plugin che consente l’esecuzione di query all’interno di Discourse, ma sembra non permettere modifiche ai dati.

Scaricare un backup (senza upload) e ripristinarlo su un’istanza locale PostgreSQL, che puoi interrogare con pgAdmin3, è la soluzione migliore.

Sì, il plug-in Data Explorer non consente di apportare modifiche. Tuttavia, ti suggerisco di iniziare comunque con quello. Puoi eseguire query per identificare se hai problemi e poi eseguire query per selezionare i record che necessitano di modifiche. In questo modo sarai protetto dal rischio di danneggiare accidentalmente il tuo database.

Suppongo che tu stia già operando in produzione, quindi sarei molto cauto nel modificare il database senza un qualche tipo di approvazione da parte del team di Discourse.

Una volta che avrai familiarità con il database di Discourse e conoscerai l’entità del problema, potrai valutare le tue opzioni per apportare le modifiche. Potresti scoprire di poter gestire tutto direttamente in Discourse. Oppure, se le modifiche sono così poche, potresti trovare adeguato l’uso della riga di comando.

Grazie, Falco!

Sono un principiante assoluto quando si tratta di usare qualsiasi cosa che non richieda solo clic e puntamento.

Tuttavia, sono riuscito a configurare un’istanza locale di Discourse (su Windows 10) seguendo le guide ufficiali (senza capire granché), quindi presumo che da qualche parte ci saranno istruzioni per installare pgAdmin3 nello stesso posto?

Domanda sciocca, ma questa istanza offline di Discourse è quella su cui dovrei ripristinare il file SQL esportato (o esiste un altro modo per ‘ripristinare’ un file di backup del database di Discourse su PostgreSQL)?
E come posso interrogarlo una volta ripristinato? Cioè, dove e come indico a pgAdmin3 il database in un’istanza di Discourse in esecuzione? Dove risiede fisicamente il database di un’istanza Discourse in esecuzione? Il fatto che l’istanza di Discourse sia in esecuzione blocca il database in qualche modo?
Non riesco a vedere alcun file che corrisponda chiaramente a un database tra i file del mio server locale nella directory ~/var/discourse.

Grazie, Remah.

Sto ospitando autonomamente Discourse, quindi non ho accesso al team di Discourse.
Sto configurando e gestendo un forum per una piccola comunità, esclusivamente su base volontaria (cioè senza budget), e sto importando dati da forum MyBB e Yahoo Groups. Questi ultimi hanno introdotto, ad esempio, una serie di vecchie notifiche email amministrative generate automaticamente come argomenti in Discourse, che sono piuttosto irrilevanti in questo contesto.

È probabile che dovrò testare e apportare modifiche globali in modo sporadico, incrementale e continuo, man mano che scoprirò nuovi problemi; da qui il desiderio di minimizzare la curva di apprendimento ed evitare qualsiasi cosa basata sulla riga di comando!

Ho visto il tuo nome di dominio e ti ho dato un’occhiata per la prima volta, quindi capisco in parte la tua situazione. A proposito, sono a Wellington, dove sto configurando e utilizzando attivamente alcuni forum privati per enti di beneficenza.

Considerando il tuo tempo limitato e la tua esperienza, ti suggerirei di iniziare con gli strumenti più semplici e facili da usare, passando al livello successivo solo se necessario. C’è un costo elevato per padroneggiare qualsiasi cosa oltre al primo livello, che consiste semplicemente nell’utilizzare Discourse stesso. Se usato come previsto, può essere incredibilmente potente.

  1. L’interfaccia grafica di Discourse con le funzionalità che dovrai comunque imparare a usare.

    • Familiarizza con ciò che devi utilizzare in Discourse. Potresti scoprire di poter fare il 99% di ciò che ti serve senza andare oltre. Quindi, forse non avrai bisogno di andare oltre.

    • Dà priorità ai problemi effettivamente visibili.
      Ad esempio, le tue vecchie notifiche email potrebbero non essere un grosso problema. Se sono irrilevanti, come previsto, perderanno importanza in Discourse man mano che vengono creati argomenti più pertinenti. È molto più importante far funzionare correttamente il tuo forum che risolvere ogni singolo errore nei dati.
      Quindi, quante di queste notifiche email automatizzate sono state convertite in argomenti?

  2. Il plugin Date Explorer ti sarà utile, quindi è il prossimo passo per una migliore comprensione del database e per identificare cosa potrebbe essere necessario fare. In seguito ti aiuterà con la generazione di report, ma non è assolutamente necessario.

    • L’impossibilità di apportare modifiche funge da rete di sicurezza, perché alcuni anni fa molti utenti danneggiavano i propri dati con aggiornamenti affrettati.

    • Le query che generi per identificare i record problematici sono a un passo dall’SQL necessario per modificare il database.

  3. L’opzione finale sarà probabilmente l’uso della riga di comando e degli script per modificare il tuo database.

    • Preferisco correre il rischio di visualizzare dati errati piuttosto che danneggiare il database modificandolo manualmente. Questo potrebbe creare una bomba a orologeria, poiché alcune corruzioni dei dati potrebbero non essere rilevate tempestivamente.

    • Utilizzare Data Explorer ti fornirà risultati delle query che sono esempi reali di dati e numeri quantificabili di record. È più probabile ottenere una risposta corretta dal team e da altri esperti se possono comprendere i tuoi dati e ciò che cerchi di ottenere. Potranno quindi consigliarti il modo più semplice e sicuro per aggiornare il database.

    • Gran parte di ciò di cui hai bisogno è probabilmente già presente in alcuni argomenti, poiché altri siti hanno affrontato problemi simili. Quindi, ti limiterai a copiare la conoscenza acquisita con difficoltà da qualcun altro.

Esatto. Non modificare mai direttamente il database. Te ne pentirai prima o poi.

Grazie, Remah.

Tutto sembra un consiglio sensato.
Potrei riuscire a ottenere una soluzione parziale tramite crowdsourcing, se riesco a convincere alcuni utenti a scansionare manualmente e segnalare i topic da eliminare.

Al momento, il sito sul dominio è essenzialmente un segnaposto pulito, mentre un freelance sta perfezionando il processo di importazione dai vecchi forum (in particolare, sta regolando lo script di importazione per MyBB, in modo che speriamo vengano importati insieme agli utenti e ai loro post anche i campi personalizzati del profilo che avevo configurato lì. Si spera anche che il codice MyBB presente in alcuni post di MyBB venga interpretato correttamente (al momento i codici di formattazione sono visibili).

Ho sprecato una settimana tentando invano di eseguire questa importazione da solo, ma non sono riuscito a creare un ambiente di sviluppo con tutti i prerequisiti necessari per farlo, né su un’istanza Ubuntu di Windows 10 né su un’istanza basata su DigitalOcean, seguendo la guida ufficiale per l’uso dello script di importazione di MyBB.

Dopo aver faticosamente navigato tra un errore e l’altro, ho finalmente sbattuto contro un muro invalicabile in entrambi i casi quando si trattava di rendere accessibile il database SQL durante l’esecuzione dell’ultimo comando Ruby on Rails che avrebbe avviato l’importazione.

Sia Linux che Ruby sembrano essere stati scritti da sadisti per masochisti: entrambi sono straordinariamente fragili e arcani. In un ambiente del genere, le probabilità di problemi catastrofici durante la manipolazione dei database sembrano davvero alte!

Le mie condoglianze.

Rimani amministratore del forum. :+1:

L’usabilità è sempre stata carente in quell’ambiente. Penso che la riga di comando sia più regina che mai, anche rispetto a 20 anni fa.

Ma è proprio per questo che mi piace Discourse. Il team si impegna a rendere il core di Discourse significativamente più amichevole. Purtroppo, la migrazione è un’opzione ad alta tecnologia.

È quasi sicuramente meglio farlo dalla console di Rails.

Immagino che possa dipendere dal tuo criterio per ‘meglio’?
Nel mio caso, essendo un principiante, la curva di apprendimento più bassa possibile e la minima complessità di accesso per chi non ha normalmente un ambiente di sviluppo configurato e non sa nulla di Ruby (o di Linux) sarebbero priorità elevate. Potrebbe essere diverso se avessi un altro motivo (e il tempo) per mettermi al passo con queste cose… In un mondo perfetto, ci sarebbe una sorta di’applicazione GUI locale per Windows che potrebbe interrogare direttamente la mia configurazione Discourse ospitata su Digital Ocean…

Se decidi di non apportare le modifiche direttamente al database, potresti trovare utili alcuni dei comandi descritti in questa pagina: Administrative Bulk Operations. Ad esempio, vengono forniti dettagli su come etichettare i topic dalla console di Rails. La cosa più importante è eseguire un backup del database del tuo sito prima di eseguire qualsiasi comando.

Il mio parametro per “Migliore” è “molto meno probabile che lasci il tuo database in uno stato rotto e completamente compromesso”. Dato che sei un “principiante”, non sai quali tabelle devono essere aggiornate quando fai… qualcosa.

Qualunque sia il metodo che usi, assicurati di eseguire backup frequenti.

Un punto valido: cercherò con impegno di trovare altre soluzioni in prima istanza.
La mia ignoranza rappresenta un rischio significativo in entrambi gli scenari, ma è corretto affermare che apportare modifiche al database tramite Ruby sia più sicuro rispetto a tentare le stesse modifiche utilizzando pgAdmin4?

È stato accennato al rischio di causare danni non immediatamente rilevati: esiste qualcosa, in un approccio rispetto all’altro, che possa influenzare tale rischio?

Nel mio pensiero, qualora decidessi di correre il rischio (dopo aver eseguito i dovuti backup), immaginavo di avere una copia di pgAdmin4 in esecuzione sul mio droplet Digital Ocean, accessibile direttamente tramite URL nel browser, piuttosto che tramite finestre della console CLI, eliminando così alcuni livelli di complessità (assumendo che ciò sia effettivamente possibile).

Quasi sempre. Ruby esegue una serie di operazioni magiche per garantire che avvenga la cosa giusta. Ad esempio, se distruggi (elimini) qualcosa da un modello, sa quando e quali altre cose devono essere eliminate. Ci sono molte operazioni “sicure” che puoi eseguire con SQL puro, ma quasi sempre preferisco farlo in Rails se è possibile.

Ah, è bello saperlo - grazie!

Sembra potenzialmente molto utile - grazie!

Come ho risolto “Come posso modificare direttamente il database di Discourse da un’interfaccia grafica?” dato che non è stata fornita la risposta che cercavo.

:warning: Non eseguire questa operazione su un server di produzione.

Questo metodo utilizza lo strumento di amministrazione raccomandato per PostgreSQL pgAdmin 4.

Questa procedura è stata eseguita sul mio computer locale per imparare di più su Discourse, ad esempio: installazione, configurazione, ottimizzazione, sviluppo di plugin, utilizzo dell’API, webhook, ecc.

Nota: Discourse è stato installato su Ubuntu 18.04 tramite WSL 2 su Windows 10, seguendo la Guida per principianti per installare Discourse su Windows 10 per lo sviluppo.

Nota: WSL 2 non include systemd di default. Problema 457.

Ho seguito come modello la guida Installare pgAdmin 4 su Ubuntu 20.04/18.04/16.04.

Utilizzando 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

Email utente pgAdmin4: postgres@localhost
Password pgAdmin4: <password 1>

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

Registra <indirizzo>

$ whoami

Registra <nome utente>

Il passaggio successivo potrebbe non essere necessario, poiché non sapevo come ottenere la password di un utente del database Postgres (non sono un esperto di PostgreSQL) o se esistesse un altro modo per configurare le credenziali di accesso al database necessarie per pgAdmin4.

$ psql postgres

Utilizzando PSQL

postgres=# ALTER ROLE <nome utente> WITH PASSWORD '<password 2>';```
---

Utilizzando un browser Internet

```bash
http://<indirizzo>/pgadmin4

utente: postgres@localhost
password: <password 1>

Una volta avviato pgAdmin4

Utilizzando pgAdmin4

Creare una connessione al server

Tab: Generale
   Nome: Discourse Development
   Gruppo server: Servers
Tab: Connessione
   Host: localhost
   Porta: 5432
   Database di manutenzione: postgres
   Nome utente: <nome utente>
   Password: <password 2>

Non è perfetto, ma funziona ed è meglio di niente. Feedback e suggerimenti sono benvenuti.


Extra

PostgreSQL
Catalogo software - Strumenti di amministrazione/sviluppo

Scopro che per la maggior parte delle azioni è più semplice e un po’ più sicuro accedere alla console di Rails piuttosto che interagire direttamente con il database.

Oppure, se ciò che vuoi fare è cambiare la password di un utente (oh, non era questo che stavi cercando di fare, ma è comunque un ottimo esempio), esegui

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

Nonostante il suo nome, questo task rake ti permetterà di:

  • creare un utente (ma va bene anche se l’utente esiste già)
  • cambiare la password (ma non è obbligatorio)
  • rendere l’utente un amministratore (ma non è obbligatorio).

Dai un’occhiata a Operazioni di amministrazione in massa per altri esempi.

Ecco alcuni di questi:

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: "Literate Computing Staff",
  grant_trust_level: 4,
  flair_url: 'https://example.com/path.icon.png'
)

Grazie per il feedback. È un’altra cosa da imparare.

Anche se ho decenni di esperienza nello sviluppo, non ho mai usato Ruby o Rails. In realtà ho iniziato a programmare con le schede perforate all’università e, personalmente, con un Atari 800.