マイグレーション後のマッピングを支援するプラグイン

開発
1

こんにちは。私たちのクレイジーな連中のグループは、Vbulletin3フォーラムをDiscourseに移行する寸前です。元のデータベースから2100万件の返信をDiscourseに移行することに成功したカスタムスクリプトを作成しました。

今、返信自体に書かれているトピック/返信へのリンクの問題があります。

移行スクリプトでは、「古い」トピックと投稿IDを、Discourseの対応するIDにマッピングしています。

例えば：

   id   | topic_id |   name    | value  |         created_at         |         updated_at
--------+----------+-----------+--------+----------------------------+----------------------------
 581727 |   581736 | import_id | 599137 | 2023-02-08 16:30:01.600759 | 2023-02-08 16:30:01.600759

今考えているのは、古いフォーマットへのリンクをインターセプトして、新しいスレッド/返信への参照に変換するプラグインです。

例えば、次のようなものです：

https://oldforum.something.com/showthread.php?t=123456

これは、topics_custom_field を値 123456 で検索し、Discourseの topic_id を見つけ、次にそのIDで topic_links テーブルをクエリして url を見つけ、クライアント側（コンテンツを操作するためのJavaScriptを想定）で投稿を置き換えるトリガーになります。

投稿についても同様のことが考えられます。

しかし、Discourseでこのようなものを作成する方法の良い例が見つかりません。

誰か、似たようなこと（返信内の特定のサブ文字列をチェックして置き換える、API？DB？をクエリして別の値を取得するなど）を行うためのヒント、例、またはプラグインを提供していただけますか？

ありがとうございます。

2

これはコアに既に存在し、パーマリンクと呼ばれています。既存のVB4インポーターには、それ用のコードが含まれています。

パーマリンク設定に「/showthread\.php\?(\d*)/thread/\1」のようなものを入力する必要があります。

「いいね！」 2
3

確認ですが、このロジックは移行が完了した後で実行すればよいのですよね？
そうすれば、すべての返信を再度確認し、パーマリンクを変更します。

4

どういう意味で変更ですか？すでにパーマリンクはありますか？

5

例えば、次のような返信のコンテンツを移行する場合：https://oldforum.something.com/showthread.php?t=123456 ディスコースでそのトピックが持つ id がわからない… ということですか？

6

上記のコードを使用してパーマリンクを作成した場合、そうなります。

showthread.php?t= は、ちなみに返信ではなく、トピック/スレッドを参照します

「いいね！」 1
7

リンクは例として使用しただけです :slight_smile:

残念ながら、2000万件の投稿のインポートに時間がかかり、一括インポートが機能しないため、そのコードを使用できません。一部が欠けています。

そのため、独自の移行スクリプトを作成しました。6コア、8GB RAMで約6時間で、すべて（プライベートメッセージ、ユーザー、ユーザーグループ、カテゴリ、トピック、返信）を行います。しかし、パーマリンクが欠けていることに気づきました :slight_smile:

8

パーマリンク前のnginxマップソリューションを検討してみてはいかがでしょうか？ Redirect vBulletin URLs to Discourse URLs

「いいね！」 1
9

内部で協議した結果、すべての返信が移行されたら、もう一度やり直すことにしました。

リチャード、アイデアを出し合ってくれてありがとう :heart:

10

スクリプトで import_ids を作成しましたか？もしそうであれば、パーマリンクを作成しなかった場合でも、それらを処理して作成することはかなり迅速に行えます。

11

はい、ジェイ、そうですね。

2000万件以上の返信をすべて再度処理することは避けようとしていましたが、代替ソリューション（プラグイン、nginxリダイレクトなど）は非常に複雑になるか、半端なソリューションになる外部要因に依存することになることに気づいたため、返信を再度処理してパーマリンクを処理することにしました。移行に時間がかかりますが、それほどではないことを願っています。

他のすべては、「生の」データをHTMLに変換する必要があることがわかっているため、その場で「調理」されます。

パーマリンクについては、編集でパーマリンクが追加された場合、まだ処理されていないトピック（より高いトピックID）を参照する可能性があり、処理時にtopics_custom_fieldテーブルで見つからない可能性があるため、そのようにはできません。

12

トピックを作成する前に、どのようにtopic_custom_fieldsを作成できたのか分かりません。以下のようなことができると思いますが、

TopicCustomField.each do |tcf|

パーマリンクを作成できますが、あなたのコードについては知らないことがたくさんあります。

13

明確にさせてください。

トピックとすべての返信は、vbulletinデータベースから小さい順にトピックIDをインポートします。それは、時系列順にインポートすることも意味します。

しかし、それは、別のトピックへの参照を見つけた場合、それは常に既に存在する別のトピックに対するものであると考えることにつながるでしょう。

しかし、そうではないケースがあります。例をいくつか挙げます。

  • 分割されたトピックと、分割につながったコメント。分割は、より小さいIDを持つトピックに存在するIDよりも大きいIDで行われます。
  • 後で読む人のための編集。古いトピックの投稿が、より最近の投稿を参照している場合。

したがって、topic_custom_field はインポートの進行中に生成および入力されますが、最初のトピックで説明したように、「オン・ザ・フライ」で行うことは、ID間の正しい対応を常に見つけることができると確信できないため、信頼性がありません。

完全なインポートが完了した後の別のパスが必要です。

TopicCustomField.each do |tcf| について、tcf の部分が何をするのかわかりません。Rubyは私が学んだ言語ではありません。私たちのスクリプトは、それを使って仕事をするために既にそれを使用しているほとんどの人々が使用しているため、C#で書かれています。

「いいね！」 1