Sto provando a fare un’importazione con l’importatore di massa di vbulletin. Sono riuscito a farlo funzionare per la maggior parte. Ha creato utenti e post, ma gli argomenti non vengono creati.
Le cose passate a create_topics(topics) sembrano corrette. Le cose in processed in base.rb:create_records sembrano corrette (skipped non è impostato). Ma non vengono creati argomenti.
Ecco l’errore:
ERROR: null value in column "pinned_globally" of relation "topics" violates not-null constraint
Ma se un argomento non è fissato globalmente, che valore dovrebbe avere? Sto provando a commentare quel campo in TOPIC_COLUMNS in base.rb.
EDIT: Penso che questo possa funzionare ma non lo saprò per un po’:
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 ha aggiunto questo:
}
t[:pinned_at] = created_at if row[8] == 1
t
end
Aha. Questo spiega perché non è nel codice, credo.
Ma non risolve il mistero.
pinned_globally | boolean | | not null | false
MODIFICA:
L’IA casuale dice:
Forse questo è uno “strumento di inserimento in blocco”?
Non riesco a trovare una fonte che affermi in modo credibile ciò che dice la citazione sopra, ma ha senso, nel senso che il punto è andare veloci, quindi saltare i valori predefiniti sembra una cosa che farebbe, e spiega cosa sta succedendo, e, spero, la soluzione che sto ancora aspettando di vedere se ha funzionato.
Se viene specificato un elenco di colonne, COPY TO copia solo i dati nelle colonne specificate nel file. Per COPY FROM, ogni campo nel file viene inserito, in ordine, nella colonna specificata. Le colonne della tabella non specificate nell’elenco di colonne COPY FROM riceveranno i loro valori predefiniti.
Quindi, se ho letto bene, se un campo è nell’elenco dei campi, allora postgres copia ciecamente ciò che gli dai e viene inserito vuoto/null invece del valore predefinito desiderato.
Sta andando sempre più lentamente. C’è un motivo per non usare LIMIT 1000 come fa l’importatore normale? Sembra che forse 885K argomenti siano troppi da affrontare in una volta?
Ho controllato lo script dell’ultimo import in blocco che ho eseguito e in effetti ha un esplicito pinned_globally: false, quindi sembra essere necessario - è l’unico valore di colonna hardcoded esplicito nel codice.
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
}
Strano che non ci sia questa impostazione per altre colonne simili con non null, default false come closed o has_summary.
[citazione=“pfaffman, post:3, topic:366162”]
Sta andando sempre più lentamente. C’è un motivo per cui non usare LIMIT 1000 come fa l’importatore normale? Sembra che forse 885K argomenti siano tanti da gestire tutto in una volta?
[/citazione]
L’ultima importazione che ho fatto con l’importatore in blocco ha gestito più di 3 milioni di argomenti in circa 2 ore. Forse hai una perdita di memoria? O forse il tuo codice MySQL (o quello che usi per leggere i dati di origine) è lento da qualche parte?
Buone notizie! Tutti gli argomenti sono stati creati! Cattive notizie! nessuno dei post è collegato ad essi, ma si spera che ciò sia dovuto al fatto che i post sono stati creati prima degli argomenti.
È strano. Ero così sicuro di avere una spiegazione.
I 7 milioni di post hanno richiesto solo un paio d’ore, ma gli argomenti (meno di 1 milione) hanno richiesto circa 4 ore.
È una macchina vecchia (che apparentemente hanno comprato solo per questo lavoro?), e mysql è remoto. Guardando htop non c’è alcuna perdita di memoria evidente a livello di sistema. Ho cancellato tutti i dati e sto ricostruendo i container per vedere se funzionerà questa volta.
