Non voglio assolutamente commettere errori, dato che ho 1,6 milioni di post.
Esiste un modo per selezionare un solo post specifico per fare dei test prima di sostituire le stringhe in tutti i post?
Ho creato un post “di prova” nel mio forum con diversi tag BB in vari contesti.
Quanto tempo richiederebbe la sostituzione di una stringa in oltre 1 milione di post?
Se richiede molto tempo, esiste un metodo più veloce? Magari modificando direttamente i testi nel database?
Esiste un modo per effettuare più sostituzioni contemporaneamente (ad esempio, aggiungere righe vuote prima e dopo i tag [quote], sostituire [b] e [i] con ** e *, rimuovere [color] e [indent], ecc.)?
Modifica: applicando queste modifiche ai contenuti grezzi dei post tramite Rails e poi rigenerando tutti i post, funzionerebbe?
Per tua informazione, a seguito della nostra migrazione da vB3 a Discourse con oltre 1 milione di post circa sei mesi fa:
Quando abbiamo migrato da vB, abbiamo eseguito tutta questa pulizia dei dati e rifattorizzazione dei tag bbcode utilizzando molto codice Ruby personalizzato nello script di migrazione.
Abbiamo scoperto che questo approccio era il migliore per noi: pulire tutto eseguendo molte espressioni REGEX Ruby gsub sui post di vB prima che venissero inseriti nel database di Discourse.
In caso contrario, dovresti eseguire molte query PostgreSQL sui post grezzi di Discourse e rigenerare i post.
Dopo test approfonditi, abbiamo deciso di eseguire tutto il preprocessing durante la migrazione (e non dopo). Abbiamo scoperto che questo è il modo “più veloce” per ottenere una migrazione perfetta.
Sai se esiste un modo per reimportare solo i post senza influire sui dati di Discourse già importati, in particolare sui dati collegati agli ID dei post (utenti, argomenti, allegati, permalink, ecc…)?
L’importazione è così lunga che se dimentico qualcosa e devo reimportare tutto da capo, ci vorranno di nuovo giorni.
Quando lo script importava i post, creava circa 50.000 post di Discourse all’ora. Perché il rebake richiede così tanto tempo in più?
Capisco perfettamente il tuo problema. Dopo la nostra migrazione originale, abbiamo scritto molto codice Ruby personalizzato per pulire oltre un decennio di codice copiato e incollato da ogni angolo del pianeta; senza contare tutti i caratteri corrotti (mojibake) e i set di caratteri strani; e senza contare i vari bbcode annidati che richiedevano molta elaborazione in Ruby per essere puliti correttamente durante la migrazione.
Non è stato un compito banale e ha richiesto molto tempo (e innumerevoli tentativi di migrazione); ma dato che siamo principalmente un forum di programmazione, se il tuo forum contiene principalmente solo testo (e non codice), dovrebbe essere più semplice.
Il nostro team ha dovuto scrivere anche molte espressioni regolari (REGEX) “abbastanza complesse per gestire questo e quello”; perché convertire tutto quel bbcode annidato legacy in markdown non è banale quando gli utenti hanno pubblicato così tanto bbcode annidato nel corso degli anni. Abbiamo anche rimosso molto bbcode che, anni dopo la pubblicazione, pensavamo avesse aggiunto poco valore.
Per rispondere alla tua domanda originale sopra:
Sì, puoi semplicemente commentare i metodi che vuoi saltare nello script di migrazione.
In realtà abbiamo riscritto gran parte dei metodi di migrazione, ma sono stati un ottimo punto di partenza e molto utili, considerando che la migrazione da vB3 non era e non è supportata.
Lo so, ma se avvio semplicemente lo script di migrazione, salterà i post esistenti.
Se elimino tutti i miei post importati da Discourse prima di riavviare la migrazione, immagino che importarli di nuovo assegnerà un ID diverso (ID del post di Discourse) rispetto alla migrazione precedente e tutti i riferimenti a questi post verranno probabilmente interrotti.
Se è possibile, è molto, molto più semplice chiedere all’importatore di sistemare queste cose. Se sei già andato online, sarà solo lungo e doloroso. Potresti escogitare uno script di importazione che modifichi i post già importati, ma non sono a conoscenza di modelli su come farlo.
