ייבוא בכמות של Vbulletin: ערך ריק בעמודה "pinned_globally" של הטבלה "topics" מפר את מגבלת not-null

מפתח
1

I’m trying to do am import with vbulletin bulk importer. I’ve managed to get it to mostly do it. It’s created users and posts, but topics are not getting created.

The stuff getting passed to create_topics(topics) looks right. The stuff in processed in base.rb:create_records looks right (skipped isn’t set). But no topics are getting created.

Here’s the error:

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

But if a topic is not pinned globally, what value should it have? I’m trying commenting out that field in TOPIC_COLUMNS in base.rb.

EDIT: I think this may do it but won’t know for a while:

    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 added this:
      }
      t[:pinned_at] = created_at if row[8] == 1

      t
    end
2

That’s odd, since that column has a default value? Does it have a default value in your database when you do \d topics ?

pinned_globally | boolean | | not null | false

3

Aha. That explains why it’s not in the code, I think.

But it doesn’t solve the mystery.

pinned_globally    | boolean   |     | not null | false

EDIT:

Random AI says:

Perhaps this a “bulk insert tool”?

I am unable to find a source that credibly says what the above quote does, but it does make sense, but in that the point of this is to go fast, so skipping defaults seems like a thing that it would do, and it does explain what is happending, and, I hope, the solution that I am still waiting to see if it worked.

Here is actual documentation! PostgreSQL: Documentation: 18: COPY

If a column list is specified, COPY TO copies only the data in the specified columns to the file. For COPY FROM , each field in the file is inserted, in order, into the specified column. Table columns not specified in the COPY FROM column list will receive their default values.

So, if I’m reading that right, if a field is in the field list, then postgres blindly copies what you give it, and blank/null gets inserted instead of the desired default.

It’s going slower and slower. Is there a reason not to use LIMIT 1000 like the regular importer does? Seems like maybe 885K topics is a lot to bite off at once?

4

בדקתי את הסקריפט לייבוא ההמוני האחרון שביצעתי והוא אכן כולל את הערך המפורש pinned_globally: false, ולכן זה כנראה הכרחי - זה הערך היחיד שהוגדר בקוד באופן מפורש מבחינה קודנית.

    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
      }

מוזר מכיוון שזה לא קיים בקטגוריות דומות אחרות שדרושות לא null, ברירת מחדל ל-false כמו closed או has_summary.

[ציטוט=“pfaffman, פוסט:3, נושא=366162”]
זה הולך לאט ויותר לאט. האם יש סיבה לא להשתמש ב-LIMIT 1000 כמו שהקוד היבואן הרגיל עושה? נראה שאולי 885K נושאים זה הרבה לנסות לטפל בבת אחת?
[/ציטוט]
הייבוא האחרון שביצעתי עם היבואן ההמוני הוביל ליותר מ-3 מיליון נושאים תוך כשעתיים. אולי יש דליפת זיכרון? או שאולי קוד MySQL שלך (או כל דבר אחר שמשמש לקריאת נתוני המקור) איטי באיזשהו מקום?

5

{“translation”: "חדשות טובות! כל הנושאים נוצרו! חדשות רעות! אף אחד מהפוסטים לא מחובר אליהם, אבל מקווה שזה בגלל שהפוסטים נוצרו לפני הנושאים.

[ציטוט="RGJ, פוסט:4, נושא:366162]
מוזר כי זה לא קורה בעמודות דומות אחרות כמו סגור או יש סיכום שיש להן לא ריק, ברירת מחדל שקר.
[/ציטוט]

זה מוזר. הייתי כל כך בטוח שיש לי הסבר. :אנושות_משהו:

[ציטוט="RGJ, פוסט:4, נושא:366162]
הייבוא האחרון שביצעתי עם היבואן הקבוצתי עשה מעל 3 מיליון נושאים תוך שעתיים או משהו כזה. אולי יש לך דליפת זיכרון? או אולי קוד MySQL שלך (או מה שאתה משתמש לקרוא את הנתוני מקור) איטי במקומות מסוימים?
[/ציטוט]

ה123 מיליון הפוסטים לקחו רק כמה שעות, אבל פחות מ-1 מיליון נושאים לקח כמו 4.

זו מכונה ישנה (שכנראה קנו אותה רק בשביל העבודה?), ו-mysql מרוחק. מבט ב-htop לא מצביע על דליפת זיכרון ברמה המערכתית. ניקה את כל הנתונים ומבצע שוב את בניית המכולות כדי לבדוק אם זה יעבוד הפעם.

תודה רבה על העזרה שלך.

לייק 1
6

ובכן, עכשיו הייבוא של user_email נכשל עם:

הֶקשר:  COPY user_emails, שורה 1: "1  \N      @gmail.com     true    2004-03-08 14:12:00 UTC 2004-03-08 14:12:00 UTC"
7

It’s taken me another several hours, but here’s why–the process_topic function handles all of those default values.

I guess there should be a

topic[:pinned_globally] ||= false

or maybe

topic[:pinned_globally] ||= topic[:pinned_at].nil?
לייק 1