Vbulletin Massenimporteur: Null-Wert in Spalte "pinned_globally" der Relation "topics" verstößt gegen die NOT-NULL-Bedingung

Entwickler
1

Ich versuche, mit dem vBulletin Bulk Importer einen Import durchzuführen. Es ist mir gelungen, ihn größtenteils zum Laufen zu bringen. Benutzer und Beiträge wurden erstellt, aber Themen werden nicht erstellt.

Die an create_topics(topics) übergebenen Daten sehen richtig aus. Die Daten in processed in base.rb:create_records sehen richtig aus (skipped ist nicht gesetzt). Aber es werden keine Themen erstellt.

Hier ist der Fehler:

ERROR:  null value in column "pinned_globally" of relation "topics" violates not-null constraint

Aber wenn ein Thema nicht global angeheftet ist, welchen Wert sollte es haben? Ich versuche, dieses Feld in TOPIC_COLUMNS in base.rb auszukommentieren.

EDIT: Ich glaube, das könnte es tun, aber ich werde es erst in einiger Zeit wissen:

    create_topics(topics) do |row|
      created_at = Time.zone.at(row[5])

      t = {
        imported_id: row[0],
        title: normalize_text(row[1]),
        category_id: category_id_from_imported_id(row[2]),
        user_id: user_id_from_imported_id(row[3]),
        closed: row[4] == 0,
        created_at: created_at,
        views: row[6] || 0,
        visible: row[7] == 1,
        pinned_globally: row[8] == 1 # <============== JP hat dies hinzugefügt:
      }
      t[:pinned_at] = created_at if row[8] == 1

      t
    end
2

Das ist seltsam, da diese Spalte einen Standardwert hat? Hat sie einen Standardwert in Ihrer Datenbank, wenn Sie \\d topics ausführen?

pinned_globally | boolean | | not null | false

3

Aha. Das erklärt, warum es meiner Meinung nach nicht im Code steht.

Aber das löst das Rätsel nicht.

pinned_globally    | boolean   |     | not null | false

EDIT:

Zufällige KI sagt:

Vielleicht ist das ein “Massen-Insert-Tool”?

Ich kann keine Quelle finden, die glaubwürdig das sagt, was das obige Zitat aussagt, aber es ergibt Sinn, denn der Sinn der Sache ist es, schnell zu sein, daher scheint das Überspringen von Standardwerten etwas zu sein, das es tun würde, und es erklärt, was passiert, und hoffentlich auch die Lösung, auf die ich immer noch warte, ob sie funktioniert hat.

Hier ist die eigentliche Dokumentation! PostgreSQL: Documentation: 18: COPY

Wenn eine Spaltenliste angegeben ist, kopiert COPY TO nur die Daten in den angegebenen Spalten in die Datei. Für COPY FROM wird jedes Feld in der Datei in der angegebenen Reihenfolge in die Spalte eingefügt. Tabellenspalten, die nicht in der COPY FROM-Spaltenliste angegeben sind, erhalten ihre Standardwerte.

Wenn ich das richtig lese, kopiert PostgreSQL bei Angabe eines Feldes im Feldverzeichnis blind, was Sie ihm geben, und anstelle des gewünschten Standardwerts wird ein leerer/NULL-Wert eingefügt.

Es wird immer langsamer. Gibt es einen Grund, LIMIT 1000 nicht zu verwenden, wie es der normale Importeur tut? Es scheint, als wären vielleicht 885.000 Themen zu viel auf einmal?

4

Ich habe das Skript für den letzten Massenimport überprüft, den ich durchgeführt habe, und es hat tatsächlich eine explizite pinned_globally: false, also ist das anscheinend notwendig – es ist der einzige explizit festgelegte Spaltenwert im Code.

    create_topics(topics) do |row|
      t = {
        imported_id: row[0],
        title: my_normalize_text(row[1]),
        category_id: category_id_from_imported_id(row[2]),
        user_id: user_id_from_imported_id(row[3]),
        created_at: Time.zone.at(row[4]),
        pinned_globally: false
      }

Seltsam, da es das bei anderen ähnlichen Spalten wie closed oder has_summary, die ebenfalls not null, default false sind, nicht hat.

[Zitat=“pfaffman, post:3, topic:366162”]
Es geht immer immer langsamer. Gibt es einen Grund, nicht LIMIT 1000 wie beim normalen Importeur zu verwenden? Es scheint, als wären 885K Themen auf einmal vielleicht zu viel?
[/Zitat]
Der letzte Import, den ich mit dem Massenimport gemacht habe, hat über 3 Mio. Themen in etwa 2 Stunden geschafft. Vielleicht hast du ein Memory-Leak? Oder deine MySQL-Konfiguration (oder was auch immer du benutzt, um die Quelldaten zu lesen) ist irgendwo langsam?

5

Gute Nachrichten! Alle Themen wurden erstellt! Schlechte Nachrichten! Keiner der Beiträge ist mit ihnen verbunden, aber hoffentlich liegt das daran, dass die Beiträge vor den Themen erstellt wurden.

Das ist seltsam. Ich war mir so sicher, dass ich eine Erklärung hatte. :person_shrugging:

Die 7 Millionen Beiträge dauerten nur ein paar Stunden, aber die weniger als 1 Million Themen dauerten etwa 4.

Es ist eine alte Maschine (die sie anscheinend extra für den Job gekauft haben?), und mysql ist remote. Wenn ich mir htop ansehe, gibt es auf Systemebene kein offensichtliches Speicherleck. Ich habe alle Daten gelöscht und baue die Container neu auf, um zu sehen, ob es dieses Mal funktioniert.

Vielen Dank für Ihre Hilfe.

1 „Gefällt mir“
6

Nun schlägt der Import von user_email fehl mit:

KONTEXT:  COPY user_emails, Zeile 1: "1  \N      @gmail.com     true    2004-03-08 14:12:00 UTC 2004-03-08 14:12:00 UTC"
7

Es hat mich weitere mehrere Stunden gekostet, aber hier ist der Grund – die Funktion process_topic behandelt all diese Standardwerte.

Ich schätze, es sollte ein

topic[:pinned_globally] ||= false

oder vielleicht

topic[:pinned_globally] ||= topic[:pinned_at].nil?
1 „Gefällt mir“