Bonjour, moi et mon groupe de fous sommes sur le point de migrer notre forum Vbulletin3 vers Discourse après avoir écrit un script ad hoc qui a finalement réussi à migrer les 21 millions de réponses de la base de données d’origine vers Discourse.
Maintenant, nous avons le problème des liens vers les sujets/réponses écrits dans les réponses elles-mêmes.
Dans la migration que nous avons écrite, nous créons une correspondance entre les anciens identifiants de sujet et de message et ce à quoi ils correspondent dans Discourse.
Par exemple :
id | topic_id | name | value | created_at | updated_at
--------+----------+-----------+--------+----------------------------+----------------------------
581727 | 581736 | import_id | 599137 | 2023-02-08 16:30:01.600759 | 2023-02-08 16:30:01.600759
Ce à quoi je pensais maintenant, c’est un plugin qui intercepte simplement les liens vers l’ancien format du forum et les transforme en référence au nouveau fil/message.
Déclencherait une recherche dans la table topics_custom_field pour la valeur 123456, trouverait l’topic_id de Discourse, puis interrogerait la table topic_links avec cet identifiant et trouverait l’url. Ensuite, il le remplacerait dans le message côté client (en supposant du JS pour manipuler le contenu).
Quelque chose de similaire pour les messages.
Cependant, je ne trouve aucun bon exemple pour commencer à créer quelque chose comme ça pour Discourse.
Quelqu’un peut-il me donner des indices, des exemples ou des plugins qui feraient quelque chose de similaire (vérifier les réponses pour une sous-chaîne et la remplacer, interroger l’API ? la base de données ? pour une valeur afin d’en récupérer une autre ?).
Juste pour confirmer, je dois exécuter cette logique une fois la migration terminée, n’est-ce pas ?
Ainsi, elle parcourt à nouveau toutes les réponses et modifie les permaliens.
Lorsque nous migrons le contenu d’une réponse avec, par exemple : https://oldforum.something.com/showthread.php?t=123456 ne sait pas quel id ce sujet aura sur Discourse… n’est-ce pas ?
Malheureusement, nous ne pouvons pas utiliser ce code car l’importation prend une éternité pour importer 20 millions de messages et l’importation en masse ne fonctionne tout simplement pas. Il manque des éléments.
C’est pourquoi nous avons dû écrire notre propre script de migration. Il fait tout (mp, utilisateurs, groupes d’utilisateurs, catégories, sujets, réponses) en environ 6 heures avec 4 cœurs, 8 Go de RAM, mais nous avons remarqué qu’il nous manquait les permaliens
Votre script a-t-il créé les import_ids ? Si oui, même si vous n’avez pas créé les permaliens, vous pouvez les traiter assez rapidement pour les créer.
Nous essayions d’éviter de parcourir à nouveau les plus de 20 millions de réponses, mais nous avons réalisé que des solutions alternatives (plugin, redirection nginx, etc.) seraient assez compliquées ou dépendraient de facteurs externes qui en feraient une solution bâclée. Nous allons donc simplement parcourir à nouveau les réponses et traiter les permaliens. Cela ajoutera du temps à la migration, mais espérons-le pas trop.
Tout le reste est “cuit” à la volée car nous savons ce qui doit être converti de “brut” en HTML.
Pour les permaliens, nous ne pouvons pas faire cela car si un permalien est ajouté avec une modification, il pourrait faire référence à un sujet qui n’a pas encore été traité (identifiant de sujet supérieur) et ceux-ci ne seraient pas trouvés dans la table topics_custom_field au moment où il est traité.
Je ne sais pas comment vous auriez pu créer des topic_custom_fields sans d’abord créer le sujet. Je penserais que vous pourriez faire quelque chose comme
TopicCustomField.each do |tcf|
et créer les permaliens, mais il y a beaucoup de choses que j’ignore sur votre code.
Les sujets et toutes leurs réponses sont importés en suivant les identifiants de sujet du plus petit au plus grand dans la base de données vbulletin. Cela signifie également que nous importons dans l’ordre chronologique.
Cependant, cela amènerait à penser que si vous trouvez une référence à un autre sujet, ce serait toujours pour un autre qui existait déjà.
Mais il y a des cas où ce n’est pas vrai, juste quelques exemples :
Sujet divisé avec un commentaire qui a conduit à la division. La division se ferait avec un identifiant plus grand mais existant dans un sujet avec un identifiant plus petit.
Modification pour les lecteurs futurs dans laquelle les anciens messages des sujets font référence à des sujets plus récents.
Donc, oui, bien que le topics_custom_field soit généré et rempli au fur et à mesure de l’avancement de l’importation, comme expliqué dans le tout premier sujet, il n’est pas fiable de le faire « à la volée » car vous ne pouvez pas être sûr de trouver toujours la bonne correspondance entre les identifiants.
Une autre passe après la fin de l’importation complète est nécessaire.
Concernant TopicCustomField.each do |tcf|, je ne suis pas sûr de ce que ferait la partie tcf. Ruby n’est pas une langue que j’ai apprise. Notre script est écrit en C# car la majorité des personnes qui ont proposé de travailler avec, l’utilisent déjà pour leur travail.
