Ja, das werde ich tun, wenn ich es schaffe, zumindest den Benutzerimport abzuschließen. Derzeit explodiert es beim Versuch, an den E-Mails zu arbeiten.
Entfernen Sie einfach die erste Zeile des Skripts script/bulk_import/vbulletin5.rb
# frozen_string_literal: true
2 „Gefällt mir“
Okay, also nur die ersten drei Funktionen ausführen:
def execute
# enable as per requirement:
#SiteSetting.automatic_backups_enabled = false
#SiteSetting.disable_emails = "non-staff"
#SiteSetting.authorized_extensions = '*'
#SiteSetting.max_image_size_kb = 102400
#SiteSetting.max_attachment_size_kb = 102400
#SiteSetting.clean_up_uploads = false
#SiteSetting.clean_orphan_uploads_grace_period_hours = 43200
#SiteSetting.max_category_nesting = 3
import_groups
import_users
import_group_users
#import_user_emails
#import_user_stats
#import_user_profiles
#import_user_account_id
#import_categories
#import_topics
#import_topic_first_posts
#import_replies
#import_likes
#import_private_topics
#import_topic_allowed_users
#import_private_first_posts
#import_private_replies
#create_oauth_records
#create_permalinks
#import_attachments
end
Ergebnis:
Ich gehe davon aus, dass die Meldung zur Sicherstellung der Konsistenz für den vollständigen Import gedacht ist? Oder sollte ich sie bei jedem „Schritt“ ausführen und dann eine Kopie des discourse-Verzeichnisses vom Host sichern?
1 „Gefällt mir“
Wenn es mit den nächsten 4 Funktionen erneut gestartet wird, wird ein Fehler für bereits vorhandene IDs zurückgegeben
Kann dies ein „Alles oder Nichts“ sein? Vielleicht wird erwartet, dass alles in einer großen Transaktion erledigt wird?
Erneut versucht. Der Prozess lief eine ganze Weile, dann plötzlich dies.
Das Frustrierende ist, dass es scheinbar aus heiterem Himmel geschieht.
Wenn ich es jetzt erneut starte, erhalte ich diesen Fehler.
Bin jetzt zu müde, um nachzusehen, worauf es sich bezieht. Insbesondere weil duplicate key value eigentlich überhaupt nicht auftreten sollte, wenn ich einfach das Bulk-Import-Skript neu gestartet habe, oder??
Ich entschuldige mich bei jedem, der sich durch diesen Beitrag angegriffen fühlt, denn ehrlich gesagt kämpfe ich seit Montag mit diesen Problemen und bin es leid, den Discourse-Code zu debuggen/hotfixen.
Nach dem n-ten Versuch (habe nach dem 7. aufgehört zu zählen) denke ich, dass ich aufgeben werde, denn es scheint, dass die Migration keine Sache ist, in die Discourse viel Zeit investiert hat, um sie zu unterstützen.
Ich glaube, das größte Problem ist, dass die in dieser riesigen Datenbank verwendete Zeichenkodierung utf8mb4 ist, die vom Skript(?) nicht unterstützt wird.
Die Verwendung von utf8 (Standard) erzeugt einfach viele Fehler, die gemeldet werden, aber es ist nicht klar, was passiert, da das Skript trotzdem weiterläuft. Wird der Eintrag in der DB übersprungen? Wird er mit nicht unterstützten Zeichen kopiert (die klassischen Quadrate)?
Darüber hinaus haben die drei verschiedenen letzten Durchläufe (mit den Massenimporteuren) mit exakt den gleichen Anweisungen unterschiedliche Ergebnisse. Dieser letzte Durchlauf erreichte den Import von Themen, begann sofort mit der Meldung von Fehlern, lief aber weiter (???):
Anwendung wird geladen...
Startet...
I18n wird vorgeladen...
Höchste Beitragsnummern werden korrigiert...
Importierte Gruppen-IDs werden geladen...
Importierte Benutzer-IDs werden geladen...
Importierte Kategorie-IDs werden geladen...
Importierte Themen-IDs werden geladen...
Importierte Beitrags-IDs werden geladen...
Gruppenindizes werden geladen...
Benutzerindizes werden geladen...
Kategorieindizes werden geladen...
Themenindizes werden geladen...
Beitragsindizes werden geladen...
Beitragsaktionsindizes werden geladen...
Kategorien werden importiert...
Übergeordnete Kategorien werden importiert...
5 - 1104/Sekunde
Untergeordnete Kategorien werden importiert...
500 - 1539/SekundeFEHLER: doppelter Schlüsselwert verletzt eindeutige Einschränkung „unique_index_categories_on_name“
DETAIL: Schlüssel (COALESCE(parent_category_id, '-1'::integer), name)=(-1, Armata Brancaleone) existiert bereits.
KONTEXT: COPY categories, Zeile 69
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/pg-1.4.5/lib/pg/connection.rb:204:in `get_last_result'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/pg-1.4.5/lib/pg/connection.rb:204:in `copy_data'
/var/www/discourse/script/bulk_import/base.rb:720:in `create_records'
/var/www/discourse/script/bulk_import/base.rb:361:in `create_categories'
script/bulk_import/vbulletin5.rb:291:in `import_categories'
script/bulk_import/vbulletin5.rb:69:in `execute'
/var/www/discourse/script/bulk_import/base.rb:98:in `run'
script/bulk_import/vbulletin5.rb:779:in `<main>'
Themen werden importiert...
600 - 4073/Sekunde
FEHLER: undefinierte Methode `[]' für nil:NilClass
/var/www/discourse/script/bulk_import/base.rb:513:in `process_topic'
/var/www/discourse/script/bulk_import/base.rb:724:in `block (2 levels) in create_records'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/mysql2/alias_method.rb:8:in `each'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/mysql2/alias_method.rb:8:in `each'
/var/www/discourse/script/bulk_import/base.rb:721:in `block in create_records'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/pg-1.4.5/lib/pg/connection.rb:196:in `copy_data'
/var/www/discourse/script/bulk_import/base.rb:720:in `create_records'
/var/www/discourse/script/bulk_import/base.rb:364:in `create_topics'
script/bulk_import/vbulletin5.rb:321:in `import_topics'
script/bulk_import/vbulletin5.rb:70:in `execute'
/var/www/discourse/script/bulk_import/base.rb:98:in `run'
script/bulk_import/vbulletin5.rb:779:in `<main>'
bis es schließlich abstürzt mit:
script/bulk_import/vbulletin5.rb:779:in `<main>'
572329 - 531/Sekunde
Antworten werden importiert...
client_loop: send disconnect: Connection reset
Aber nicht bevor ständig diese beiden Fehler gemeldet wurden:
FEHLER: undefinierte Methode `gsub!' für nil:NilClass
script/bulk_import/vbulletin5.rb:727:in `preprocess_raw'
script/bulk_import/vbulletin5.rb:369:in `block in import_topic_first_posts'
/var/www/discourse/script/bulk_import/base.rb:723:in `block (2 levels) in create_records'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/mysql2/alias_method.rb:8:in `each'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/mysql2/alias_method.rb:8:in `each'
/var/www/discourse/script/bulk_import/base.rb:721:in `block in create_records'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/pg-1.4.5/lib/pg/connection.rb:196:in `copy_data'
/var/www/discourse/script/bulk_import/base.rb:720:in `create_records'
/var/www/discourse/script/bulk_import/base.rb:367:in `create_posts'
script/bulk_import/vbulletin5.rb:361:in `import_topic_first_posts'
script/bulk_import/vbulletin5.rb:71:in `execute'
/var/www/discourse/script/bulk_import/base.rb:98:in `run'
script/bulk_import/vbulletin5.rb:779:in `<main>'
und
FEHLER: ungültige Byte-Sequenz in UTF-8
script/bulk_import/vbulletin5.rb:727:in `gsub!'
script/bulk_import/vbulletin5.rb:727:in `preprocess_raw'
script/bulk_import/vbulletin5.rb:369:in `block in import_topic_first_posts'
/var/www/discourse/script/bulk_import/base.rb:723:in `block (2 levels) in create_records'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/mysql2/alias_method.rb:8:in `each'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/mysql2/alias_method.rb:8:in `each'
/var/www/discourse/script/bulk_import/base.rb:721:in `block in create_records'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/pg-1.4.5/lib/pg/connection.rb:196:in `copy_data'
/var/www/discourse/script/bulk_import/base.rb:720:in `create_records'
/var/www/discourse/script/bulk_import/base.rb:367:in `create_posts'
script/bulk_import/vbulletin5.rb:361:in `import_topic_first_posts'
script/bulk_import/vbulletin5.rb:71:in `execute'
/var/www/discourse/script/bulk_import/base.rb:98:in `run'
script/bulk_import/vbulletin5.rb:779:in `<main>'
Bitte beachten Sie, dass ich Schritt für Schritt vorgegangen bin, indem ich kommentiert habe, welche Funktion ausgeführt werden soll, dann rake import:ensure_consistency ausgeführt habe, bevor ich mit dem Kommentieren der bereits ausgeführten Funktionen fortgefahren bin, und so weiter, denn wenn ich das gesamte Skript einfach wiederholen lasse, stürzt es einfach ab, indem es doppelte IDs findet.
Bevor das übliche Argument „man kann sich nicht über kostenlose Software beschweren“ aufkommt, möchte ich klarstellen, dass ich zu anderen Open-Source-Projekten beigetragen habe und ebenfalls kostenlose Software entwickle, aber es ist mir äußerst wichtig, dass, wenn ich etwas veröffentliche, es funktioniert und gut dokumentiert ist (auch nur, um die Tausenden von Nachrichten zu vermeiden, die zu Recht fragen: „Wie funktioniert das?“) oder ich bin bereit, jeden aufkommenden Fehler zu beheben.
Während Discourse eine großartige Out-of-the-Box-Erfahrung zu bieten scheint, sollte klar sein, dass wir uns im Jahr 2022 befinden und Gemeinschaften lange vor diesem Produkt existierten. „Adoption“ würde eine starke Migrationsunterstützung erfordern, und das scheint derzeit nicht der Fall für Discourse zu sein.
Ich erkenne an, dass eine 20-GB-Datenbank ein Ausnahmefall ist, aber wir haben hier keine Probleme mit der Größe, sondern eher mit der Zeichenkodierung oder was auch immer, da es nicht einmal einen konstanten Fehler gibt und die meiste Dokumentation besteht darin, Fäden und Beiträge zu jagen, die von denen hinterlassen wurden, die die gleiche Tortur in der Vergangenheit durchgemacht haben, in der Hoffnung, dass ein Workaround gefunden wurde und dass der Quellcode sich seitdem nicht wesentlich geändert hat.
Zu diesem Zeitpunkt würde ich jedem, der von vBulletin kommt, dringend empfehlen, mit der Migration zu warten, bis die Überarbeitung des Migrationsskripts (die anscheinend im Gange ist?) abgeschlossen ist.
Obwohl ich deinen Schmerz verstehe (Migrationen sind ein schwieriges Thema), möchte ich als Migration Specialist bei Discourse die Dinge richtigstellen.
Wir haben ein ausgereiftes Migrationsframework mit über 60 Skripten für verschiedene Plattformen, ein separates Bulk-Framework mit 5 Skripten und ein neueres Framework in Arbeit, das jeden Aspekt massiv verbessert – Leistung, Codeorganisation, Testbarkeit, Überprüfbarkeit, Dokumentation und so weiter.
Wir haben ein separates Migrationsteam mit umfangreicher Unterstützung durch Kernentwickler und wir tragen bei jeder abgeschlossenen Migration allgemeine Verbesserungen in den Code zurück. Wir führen ständig Migrationen für Kunden durch, die von trivial bis unglaublich komplex reichen.
Unser Endziel ist es, Migrationen sowohl für gehostete Kunden als auch für die Community so reibungslos wie möglich zu gestalten, aber der Umfang des Codes, der während einer Migration im Geltungsbereich liegt, ist einfach zu riesig, und systemweite Softwarekonfigurationen, Änderungen an Drittanbietersoftware und die Variabilität der Eingabedaten verschärfen das Problem nur noch.
Nochmals, ich wünschte, all diese Dinge wären schmerzloser, aber sie so zu machen, erfordert unzählige Arbeitsstunden zur Erstellung und Wartung, und davon gibt es nur eine begrenzte Anzahl.
Gib nicht auf! 
5 „Gefällt mir“
Ich weiß es zu schätzen und verstehe, dass der Umfang immens ist. Es ist einfach frustrierend, immer wieder auf Ausnahmen zu stoßen, und die Tatsache, dass das Projekt in Ruby geschrieben ist, hilft nicht dabei, Hilfe zu finden, außer im Grunde hierher zu kommen, was, wie Sie sagen, unmöglich alle Hilfsanfragen erfüllen kann, da einige sehr spezielle Fälle haben, bei denen es einfach unmöglich ist zu helfen, es sei denn, man hat Zugriff auf die tatsächlichen Daten.
Ich gebe auch zu einem großen Teil der absoluten Clusterfuck-Struktur von vbulletin die Schuld.
Ich habe gerade heute Morgen nachgesehen und hier ist eine Zusammenfassung der Tabellengrößen.
Um Kontext zu geben, die Tabelle “text” ist dort, wo der eigentliche Inhalt ist.
Die Tabelle node speichert die Hierarchie und closure… lassen Sie mich hier zitieren, weil ich es nicht einmal kann:
Die Closure-Tabelle baut die Eltern-Kind-Beziehungen zwischen allen Knoten auf. Der Großteil Ihrer Datenbank besteht aus angehängten Dateien, die sowieso nicht in der Datenbank gespeichert werden sollten.
Also insgesamt gibt es bei einem Forum mit ca. 8 GB Inhalt einen Overhead von 28 GB. Tolle Sache, Glückwunsch vbulletin.
2 „Gefällt mir“
Das meine ich, wenn ich sage, dass es frustrierend ist.
Wieder die gleiche Vorgehensweise (ein von mir selbst geschriebenes Runbook mit all den Fehlversuchen befolgend), das auf einer neuen Discourse-Installation ausgeführt wird.
Ergebnis:
Wo bist du import_user_account_id? 
Aber am wichtigsten? Wie hast du es geschafft, beim vorherigen Lauf, bei dem der Import des Themas fehlschlug, keinen Fehler zu verursachen? 
Auskommentieren dieses Funktionsaufrufs (der sowieso wichtig zu sein scheint) und erneutes Starten:
Diese Fehler mit doppelten Schlüsseln… sollte das Skript nicht wissen, dass es diese IDs bereits verarbeitet hat und weitermachen?
Jeder Import ist anders. Man sollte meinen, dass ein Skript, das für eine Instanz von your-previously-favorite-forum funktioniert, einfach funktioniert, aber das tut es nicht. Und für ein riesiges Forum ist es wirklich schwierig. Es ist einfach nichts, was leicht zu unterstützen ist. Und die Massenimporte greifen direkt auf die Datenbank zu, anstatt sich darauf zu verlassen, dass Rails automatisch Dinge überprüft, während es läuft.
Das ist ein nicht so seltenes Problem und nicht die Schuld des Skripts. Sie müssen herausfinden, wie Sie Ihre alte Datenbank nach utf8 migrieren können.
Es gibt eine starke Migrationsunterstützung. Es gibt nur keine kostenlose Migrationsunterstützung. Ich habe etwa 100 Migrationen durchgeführt und mehrere Importskripte für nicht unterstützte oder proprietäre Systeme geschrieben. Ich würde wahrscheinlich 3000-5000 US-Dollar berechnen, um Ihre Datenbank zu importieren. Das ist kein Angebot, sondern nur, um Ihnen eine Vorstellung davon zu geben, wie viel Arbeit es für jemanden ist, der es schon oft gemacht hat. Ich vermute, dass CDCK dies kostenlos tun würde, wenn Sie ein Jahr lang Business Hosting bezahlen würden, was weniger sein könnte, als ich dafür berechnen würde. (Oh, aber Sie sind möglicherweise nicht für Business Hosting mit einer so großen Datenbank berechtigt).
1 „Gefällt mir“
Ich setze meine Erkundung hier fort.
- Das Skript verweist auf eine Funktion, die nicht existiert:
import_user_account_id. Ihr (Discourse-Entwickler) solltet das vielleicht beheben. - Die Logik, die die Titel von Themen überprüft, gerät aus irgendeinem Grund bei einigen Themen in Schwierigkeiten, die aus irgendeinem Grund einen leeren String als Titel haben. So sehr das auch nicht passieren sollte, die Überprüfung, die das auswertet sollte es abfangen und
nilzurückgeben, aber anscheinend bricht das die nachfolgende Logik, die im Import geschrieben ist (siehe hier).
Ich hatte dieses Problem bei einem Import, den ich in letzter Zeit durchgeführt habe. Besser wäre es, wenn es etwas wie „Thema XXX fehlt ein Titel“ zurückgeben würde oder die erste Textzeile aus dem Beitrag ziehen würde, aber das ist in diesem Kontext schwer zu bewerkstelligen. Ich denke, ich würde versucht sein, es zu beheben, indem ich meine Datenbank verändere und etwas anderes verwende, um Titel zu generieren, wo sie fehlen.
Ja, ich “bereinige” die Datenbank im Grunde, wenn ich diese Probleme finde, aber es ist einfach schwierig, da ich das Skript debuggen und jedes Mal erraten muss, was das Problem verursacht 
Immer noch keine Ahnung von der fehlenden Funktion import_user_account_id
Besonders da die Feiertage sehr bald kommen, ist es unwahrscheinlich, dass jemand das repariert, es sei denn, er benutzt das Skript selbst. (Normalerweise sage ich das und Richard kommt und rettet den Tag.)
2 „Gefällt mir“
LOL, nun, ich schätze, ich werde dich heute enttäuschen. Ich habe es versucht, aber ich vermute, dass der Commit dieses Importers unvollständig war und einige Änderungen an base.rb nicht enthielt. @justin hat daran gearbeitet, vielleicht weiß er es. Ich vermute, dass dies etwas Kundenspezifisches gewesen sein könnte, das ohne weitere Konsequenzen auskommentiert werden kann.
Ich selbst habe die Massenimporteure noch nie benutzt.
Ja, Importskripte können komplex sein und von den spezifischen Datenbanken abhängen, aber einige Skripte sind einfach nicht in einem funktionierenden Zustand. Das gilt auch für dieses hier, und es gibt noch einige weitere Skripte mit z.B. # frozen_string_literal: true, die einfach nicht out-of-the-box funktionieren.
2 „Gefällt mir“
Ha!
Das ist (zumindest)
Teil davon, warum ich es so schwierig finde, PRs für die von mir vorgenommenen Änderungen einzureichen. Bis ich fertig bin, gibt es so viel fallspezifischen Kram darin, dass ich befürchte, alles, was ich einreiche, wird irgendwie kaputt sein.
Ja. Ich denke, etwas ist durchgelaufen und hat frozen_string_literal zu jeder Datei hinzugefügt. Die meisten Dateien wurden repariert, weil sie Tests hatten, aber für die Importskripte gibt es keine Tests.
2 „Gefällt mir“
Hey, nur zur Klarstellung, ich erwarte nicht, dass jemand das jetzt behebt (im Karen-Stil). Ich weise nur auf einige Dinge hin, die eindeutig Probleme im Code selbst haben und wahrscheinlich nur “ups, ich habe vergessen, diese Änderung in den Commit aufzunehmen! ” sind.
Ich habe bereits akzeptiert, dass diese Migration frühestens im Januar stattfinden wird, zu diesem Zeitpunkt.
Alle sollten einfach die Feiertage genießen
Ich werde das nach den Feiertagen ansprechen oder einen neuen Thread eröffnen, auch wenn ich definitiv weniger Zeit für diese Migration haben werde 
2 „Gefällt mir“
Ja, absolut richtig – für Importe reiche ich normalerweise keine PR ein, bevor ich zwei Importe von verschiedenen Kunden durchgeführt habe.
1 „Gefällt mir“
Ich halte das hier auf dem Laufenden.
Ich habe einige Änderungen an base.rb vorgenommen, nachdem ich sie mit einigen anderen Ingenieuren in unserer Community besprochen hatte. Viele Fehler wurden durch gsub! verursacht, da es anscheinend einige Themen mit '' als Titel gab.
Wir haben eine Funktion hinzugefügt, die der Funktion normalize_text ähnelt und einfach die imported_id des Threads zurückgibt, wenn kein Inhalt vorhanden ist, umgewandelt in einen String.
def normalize_text_thread(text, imported_id)
return imported_id.to_s unless text.present?
@html_entities.decode(normalize_charset(text.presence || "").scrub)
end
Dann habe ich in vbulletin5.rb die Zeile in create_topic geändert in:
create_topics(topics) do |row|
created_at = Time.zone.at(row[5])
title = normalize_text_thread(row[1], row[0])
Das hat das Problem behoben. Im Grunde kommt gsub! nicht gut damit zurecht, wenn nil als Eingabe kommt.
Dies führte jedoch dazu, dass das Skript weiterlief, aber als es import_private_topics erreichte, hing es dort. Es gibt 253.427 private Themen (PMs) in unserer Datenbank, was um mehrere Größenordnungen weniger ist als Antworten. Nach 9 Stunden habe ich das Skript gestoppt, um zu sehen, was tatsächlich los war.
Als ich die Benutzeroberfläche aufrief, bemerkte ich ein paar Dinge.
- Mein Konto wurde nicht importiert, da der erstellte Admin-Benutzer vermutlich dieselbe E-Mail-Adresse verwendete. Offensichtlich, aber etwas, das vielleicht irgendwo aufgeschrieben werden sollte?
- Nur einige der Kategorien (vBulletin-Unterforen) wurden importiert.
- Nur Themen und ihre erste Antwort wurden importiert (nicht sicher, ob wirklich alle) und sie wurden alle importiert, ohne in den richtigen Kategorien zu sein, selbst diejenigen, die eine Kategorie hatten, die hätte erstellt werden sollen. Alles wird “ohne Kategorie” importiert.
- Der “Antwortenzähler” zeigt
-1an, wahrscheinlich weil die Antworten tatsächlich gar nicht importiert wurden.
Ich werde das Gesamtbild hinzufügen. VIELE Probleme mit diesem Massenimport würden verschwinden, wenn eine Paginierungsansatz implementiert wäre. Ich denke, die Antworten sind verloren gegangen, weil das Skript versucht hat, sie alle auf einmal zu verarbeiten, und bei 7 GB Daten war das unmöglich. Es ist mir ehrlich gesagt ein Rätsel, dass ein Massenimporteur den Import nicht mit einem Paginierungsansatz angeht. Selbst das einfache Aufnehmen von 1000 Datensätzen auf einmal, das Schreiben und Speichern der zuletzt geschriebenen Datensatz-ID und das Schleifen würde alle Probleme mit großen Datenbanken lösen.
1 „Gefällt mir“
Nur zur Info, ich verfolge das mit Interesse und weiß die Updates sehr zu schätzen. 
Ich weiß noch nicht viel über Migrationen, aber ich finde das hier sehr informativ.
4 „Gefällt mir“