ユーザーフレンドリーなユーティリティを探しています。2つの異なる古いフォーラムからインポートされた投稿とユーザーを含む現在のデータベースを全体的に整理できるSQLクエリを実行できるものです。例えば、トピックの削除、タイトルに特定の文字列を含むすべての投稿への特定のタグの追加、ユーザーの削除、またはユーザープロフィールが特定の基準を満たさない場合のアクセス権の変更などが可能です。
phpMyAdminのように、Discourseの管理者用SQLバックアップを編集できる、あるいはライブのDiscourseインスタンスと連携できるツールは存在しますか？
Discourse内でクエリを実行できるプラグインがあることは確認できましたが、データの書き換えはできないようです。
アップロードを含まないバックアップをダウンロードし、ローカルインスタンスの PostgreSQL に復元して、pgAdmin3 でクエリを実行するのが最善の手段です。
はい、データエクスプローラープラグインでは変更を加えることはできません。ただし、まずはそこから始めることをお勧めします。クエリを実行して問題の有無を確認し、その後、変更が必要なレコードを選択するクエリを実行できます。これにより、データベースを誤って破損させるリスクから保護されます。
すでに本番環境で運用されていると想定されますが、Discourse チームからの何らかの承認を得ずにデータベースを変更するのは非常に慎重になるべきです。
Discourse のデータベースに慣れ、問題の規模を把握したら、変更を行う方法について検討できます。Discourse 上で全て対応できる場合もあれば、変更が非常に少ないためコマンドラインで十分という場合もあるでしょう。
ファルコ、ありがとう！
ポインティング＆クリック以外の操作については、私は本当に初心者です。
しかし、公式ガイドに従って（ほとんど何も理解していないまま）、Windows 10 上で Discourse のローカルインスタンスをセットアップすることができました。おそらく、pgAdmin3 を同じ場所にインストールするためのガイドもどこかにあるはずです。
愚かな質問かもしれませんが、このオフラインの Discourse インスタンスは、エクスポートした SQL ファイルを復元すべき対象でしょうか（それとも、Discourse のデータベースバックアップファイルを PostgreSQL に復元する別の方法があるのでしょうか）。
また、復元後どのようにクエリを実行すればよいのでしょうか？つまり、pgAdmin3 を実行中の Discourse インスタンスのデータベースにどのように接続すればよいのでしょうか？実行中の Discourse のデータベースは物理的にどこに存在するのでしょうか？Discourse インスタンスが実行されていることが、データベースを何らかの方法でロックしているのでしょうか？
ローカルサーバーの /var/discourse ディレクトリ内のファイルの中から、明らかにデータベースに対応するファイルを見つけることができません。
レマー、ありがとう
Discourse をセルフホスティングしているため、Discourse チームにはアクセスできません。
小規模なコミュニティ向けにフォーラムを立ち上げ、運営していますが、これは完全にボランティアベース（つまり予算なし）です。MyBB と Yahoo グループのフォーラムからデータを移行しているところですが、後者から Discourse に移行した際、例えば古い管理用自動生成メール通知がトピックとして取り込まれてしまい、この文脈ではあまり関連性がありません。
新たな問題が発見されるたびに、断続的かつ段階的にテストを行い、グローバルな変更を加える必要がある可能性が高いです。そのため、学習曲線を最小限に抑え、CLI ベースの操作を避けたいと考えています。
ドメイン名を確認して初めてサイトを拝見しましたので、あなたの状況はなんとなく理解できます。ちなみに私はウェリントンにいて、いくつかの慈善団体のプライベートフォーラムを立ち上げて、実際に運用しています。
限られた時間と経験をお考えであれば、まずは最もシンプルで使いやすいツールから始め、やむを得ない場合のみ次の段階に進むことをお勧めします。Discourse 自体の利用という第一段階を超えると、習得には非常に高いコストがかかります。しかし、設計通りに使えば、Discourse は驚くほど強力なツールです。
必要な機能を備えた Discourse の GUI
Discourse で必要な機能に慣れましょう。実は、それ以上のステップに進まなくても、必要なことの 99% は対応できるかもしれません。つまり、それ以上先に進む必要がないかもしれません。
目に見える実際の課題を優先してください。
例えば、古いメール通知が大きな問題でないこともあります。無関係な通知であれば、Discourse の設計通り、より関連性の高いトピックが作成されるにつれて、目立たなくなっていきます。すべてのデータエラーを解決するよりも、フォーラムを正常に運用し始めることの方が重要です。
では、これらの自動メール通知のうち、何件がトピックに変換されているでしょうか？
Date Explorer プラグインはデータベースの理解を深め、必要な対応を特定するために役立ちますので、次のステップとなります。将来的にはレポート作成にも役立ちますが、必須ではありません。
変更を制限できないことは安全策です。数年前には、多くのユーザーが急な更新によってデータを破損させていたからです。
問題のあるレコードを特定するために生成するクエリは、データベースを変更する SQL とほぼ同じものです。
最後の選択肢は、おそらくコマンドラインやスクリプトを使用してデータベースを変更することになるでしょう。
私は、データベースを損なうリスクを冒すよりも、間違ったデータが表示されるリスクを許容する方がマシだと考えます。手動でデータベースを変更すると、データ破損がタイムリーに検出されない場合があり、時限爆弾のような状態になる可能性があります。
Data Explorer を使えば、クエリ結果として実際のデータ例と、レコード数の定量的な数値が得られます。チームや他の専門家があなたのデータと達成しようとしていることを理解できれば、正しい回答を得られる可能性が高まります。そして、データベースを更新する最も簡単で安全な方法について助言を受けることができます。
必要なことの多くは、すでに他のサイトでも同様の問題に直面しているため、既存のトピックに含まれている可能性が高いです。つまり、他の人が苦労して得た知識をそのまま活用できるということです。
その通りです。データベースを直接変更しないでください。いつか後悔することになります。
レマー、ありがとう
すべて理にかなったアドバイスですね。
もしいくつかのユーザーを説得して、手動でトピックを検索し削除対象としてマークさせることができれば、部分的な解決策をクラウドソーシングできるかもしれません。
現在、ドメイン上のサイトは、旧フォーラムからのインポートプロセスを微調整しているフリーランサーが作業中の、実質的にクリーンなプレースホルダー状態です。特にMyBB向けのインポートスクリプトを調整しており、カスタムユーザープロフィールフィールドがユーザーや投稿と一緒にインポートされることを期待しています。また、MyBBの投稿に含まれるMyCodeの解析も正しく行われることを願っています（現在はフォーマットコードがそのまま表示されてしまっています）。
私は公式ガイドに基づき、Windows 10上のUbuntuインスタンスまたはDigitalOceanのインスタンスのどちらからもインポートを実行できる開発環境を構築しようとして、無駄に1週間を費やしてしまいました。
エラーメッセージを次々と解決しながら苦悶のうちに試行錯誤を続けた結果、最終的にインポートを開始するRuby on Railsコマンドを実行する際に、SQLデータベースへのアクセスが不可能という絶対的な壁に直面し、どちらの環境でも行き詰まりました。
LinuxもRubyも、どちらも驚くほど脆弱で難解であり、サディストがマゾヒストのために書いたのではないかと思うほどです。そのような環境でデータベースを操作する際、壊滅的な問題が発生する確率は確かに高いように思えます！
お気持ち、お察しします。
フォーラム管理者に専念なさってください。:＋1:
あの環境では、昔からユーザーフレンドリーさが欠けていました。コマンドラインは、20 年前よりも今の方がさらに王様だと思います。
しかし、それが私が Discourse を好きな理由です。チームは、Discourse のコアをより大幅に使いやすくするために努力しています。残念ながら、移行は高度な技術が求められる選択肢です。
それを行うには、Rails コンソールから行う方がほぼ間違いなく適切です。
「より良い」の基準によっては異なるかもしれませんね。
私の場合、初心者であるため、学習曲線を可能な限り低くし、普段は開発環境をセットアップしておらず、Ruby（もちろん Linux についても）の知識がない人にとってのアクセスの最小限の複雑さが最優先事項です。もしこれらのことについて習得する理由や時間があったなら、事情は異なるかもしれません… 理想的な世界では、デジタルオーシャン上でホストされている Discourse 設定を直接問い合わせるような、何らかの GUI ローカル Windows アプリが存在するはずです…
データベースに直接変更を加えないと決めた場合、このトピックで説明されているコマンドの一部が役立つかもしれません: https://meta.discourse.org/t/administrative-bulk-operations/118349。例えば、rails コンソールからトピックにタグを付ける方法の詳細が記載されています。最も重要なのは、コマンドを実行する前にサイトのデータベースをバックアップすることです。
私の「より良い」の基準は、「データベースが破損したり、完全に壊れたりする可能性がはるかに低いこと」です。あなたは「初心者」なので、何かを行う際にどのテーブルを更新する必要があるのか分からないでしょう。
どのような方法を選ぼうとも、頻繁にバックアップを取ることを忘れないでください。
もっともなご指摘です。まずは他の方法を模索してみます。
どちらのシナリオでも、私の無知は大きなリスクですが、Ruby を通じてデータベースの変更を行う方が、pgAdmin4 を使用して同じ変更を試みるよりも安全だと言えるでしょうか？
例えば、すぐに気づかれない損害を生むリスクについても触れられていますが、このリスクに影響を与えるような、どちらかのアプローチ固有の要因はありますか？
頭の片隅では、もしリスクを冒すことを決意した場合（適切なバックアップを取った後）、Digital Ocean のドロップレット内で pgAdmin4 のコピーを動作させ、ブラウザの URL から直接アクセスできるようにし、CLI コンソールウィンドウ経由ではなく、これによっていくつかの複雑なレイヤーを排除することを想定していました（これが可能かどうかは別として）。
ほぼその通りです。Ruby は、正しい処理が行われるようにするためのさまざまなマジックを実行します。例えば、モデルから何かを破壊（削除）すると、いつ、何を削除すべきかを自動的に認識します。生 SQL でも安全に行える操作はたくさんありますが、可能であれば、私はほぼ常に Rails 内で処理を行います。
ああ、それは知れてよかったーありがとう！
とても役に立ちそうですね。ありがとうございます！
「Discourse データベースを GUI から直接編集するには？」という質問への回答が私の求めていたものではなかったため、私がどのように解決したかをご紹介します。
本番環境のマシンでこの操作を行わないでください。
これは PostgreSQL の推奨管理ツール pgAdmin 4 を使用しています。
これは Discourse についてさらに学ぶため（インストール、設定、チューニング、プラグインの開発、API や webhooks の利用など）に、ローカルマシンで行ったものです。
注：Discourse は、Windows 10 での開発用 Discourse インストール初心者ガイド に従い、Windows 10 上の WSL 2 にて Ubuntu 18.04 にインストールされました。
注：WSL 2 には systemd が含まれていません。Issue 457
テンプレートとして Ubuntu 20.04/18.04/16.04 への pgAdmin 4 のインストール を使用しました。
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
pgAdmin4 ユーザーのメールアドレス: postgres@localhost
pgAdmin4 のパスワード: <password 1>
$ sudo /etc/init.d/apache2 restart
$ sudo ufw allow http
$ sudo ufw allow https
$ hostname -I
<address> を記録
$ whoami
<user name> を記録
次のステップは不要かもしれません。PostgreSQL の専門家ではないため、Postgres DB ユーザーのパスワードを取得する方法がわからなかったか、pgadmin4 に必要な DB ログインを設定する別の方法があったかどうか不明だったためです。
$ psql postgres
PSQL を使用
postgres=# ALTER ROLE <user name> '<password 2>'; -- 実際には ALTER ROLE <user name> WITH PASSWORD '<password 2>'; のように記述する必要があります
インターネットブラウザを使用
http://<address>/pgadmin4
ユーザー: postgres@localhost
パスワード: <password 1>
pgAdmin4 が起動したら
pgAdmin4 を使用
サーバー接続の作成
タブ: General
Name: Discourse Development
Server group: Servers
タブ: Connection
Host: localhost
Port: 5432
Maintenance database: postgres
Username: <user name>
Password: <password 2>
完璧ではありませんが、動作しており、何もしないよりはましです。フィードバックやご提案を歓迎します。
ボーナスラウンド
PostgreSQL
ソフトウェアカタログ - 管理/開発ツール
ほとんどの操作において、データベースに直接アクセスするよりも、Rails コンソールにアクセスする方が簡単で、やや安全だと感じています。
あるいは、ユーザーのパスワードを変更したい場合（ああ、それはあなたがしようとしていたことではありませんが、これは良い例です）、以下を実行してください。
cd /var/discourse
./launcher enter app
rake admin:create
名前の通り、この rake タスクでは以下の操作が可能です。
他の例については、Administrative Bulk Operations をご覧ください。
以下にいくつかの例を示します。
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'
)
フィードバックありがとうございます。また一つ学ぶことができました。
私は何十年もの開発経験がありますが、Ruby や Rails を使ったことは一度もありません。実際、私は大学でパンチカードを使ってプログラミングを学び、個人では Atari 800 でプログラミングを始めました。