Je ne veux absolument pas commettre d’erreurs, car j’ai 1,6 million de messages.
Existe-t-il un moyen de cibler un seul message spécifique pour effectuer des tests avant de remplacer les chaînes dans tous les messages ?
J’ai créé un message de « test » dans mon forum contenant plusieurs balises BB dans divers contextes.
Combien de temps prendrait un remplacement de chaîne dans plus d’un million de messages ?
Si cela prend beaucoup de temps, existe-t-il une méthode plus rapide ? Peut-être en modifiant directement les textes dans la base de données ?
Existe-t-il un moyen d’effectuer plusieurs remplacements à la fois (par exemple, ajouter des sauts de ligne avant et après les balises [quote], remplacer [b] et [i] par ** et *, supprimer [color] et [indent], etc.) ?
Édit : appliquer ces modifications sur le contenu brut des messages via Rails, puis reconstruire tous les messages (rebake) ferait-il l’affaire ?
Pour information, suite à notre migration de 1 million de messages de vB3 vers Discourse il y a environ six mois :
Lors de notre migration depuis vB, nous avons effectué tout ce nettoyage de données et cette refonte des balises bbcode en utilisant beaucoup de code Ruby personnalisé dans le script de migration.
Nous avons constaté que c’était la meilleure approche pour nous : tout nettoyer en exécutant de nombreuses expressions REGEX Ruby gsub sur les messages vB avant leur insertion dans la base de données Discourse.
Sinon, vous devrez exécuter de nombreuses requêtes PostgreSQL sur les messages bruts de Discourse et retransformer les messages.
Après des tests approfondis, nous avons décidé d’effectuer tout le prétraitement pendant la migration (et non après). Nous avons trouvé que c’était la méthode la plus rapide pour obtenir une migration parfaite.
Savez-vous s’il existe un moyen de réimporter uniquement les publications sans affecter les données Discourse déjà importées, en particulier les données liées aux IDs des publications (utilisateurs, sujets, pièces jointes, permaliens, etc.) ?
L’importation est si longue que si j’oublie quelque chose et que je dois tout réimporter, cela prendra encore des jours.
Lorsque le script importait les publications, il créait environ 50 000 publications Discourse par heure. Pourquoi le rebake prend-il beaucoup plus de temps ?
Je comprends votre situation. Après notre migration initiale, nous avons écrit beaucoup de code Ruby personnalisé pour nettoyer plus d’une décennie de code copié-collé depuis toutes les régions du monde ; sans parler de tous les problèmes de codage de caractères (mojibake) et des jeux de caractères étranges ; et sans oublier tous les divers codes BB imbriqués qui nécessitaient beaucoup de traitement Ruby pour être nettoyés proprement lors de la migration.
Cela n’a pas été une tâche triviale et a pris beaucoup de temps (avec d’innombrables tentatives de migration) ; mais nous sommes / étions principalement un forum de développement, donc si votre forum contient principalement du texte (et peu de code), la tâche devrait être plus simple.
Notre équipe a dû écrire de nombreuses expressions régulières (REGEX) « quelque peu complexes pour échapper ceci et cela » ; car convertir tout ce code BB legacy imbriqué en Markdown n’est pas trivial lorsque les utilisateurs ont publié tant de code BB imbriqué au fil des ans. Nous avons également supprimé beaucoup de codes BB qui, selon nous, ajoutaient peu de valeur plusieurs années après leur publication.
Pour répondre à votre question initiale ci-dessus :
Oui, vous pouvez simplement commenter les méthodes que vous souhaitez ignorer dans le script de migration.
Nous avons en réalité réécrit une grande partie des méthodes de migration, mais elles constituaient un excellent point de départ et étaient très utiles, étant donné que la migration vB3 était et reste non prise en charge.
Je le sais, mais si je lance simplement le script de migration, il ignorera les publications existantes.
Si je supprime toutes mes publications importées depuis Discourse avant de relancer la migration, je suppose que les réimporter attribuera un nouvel identifiant (ID de publication Discourse) différent de celui de la migration précédente, et toutes les références à ces publications seront probablement brisées.
Si c’est possible, il est beaucoup plus simple de demander à l’importateur de corriger ces éléments. Si vous êtes déjà en production, cela risque d’être long et pénible. Vous pourriez concevoir un script d’importation qui modifie les publications déjà importées, mais je ne connais aucun modèle pour le faire.
