Salut, ce sujet donne un peu de contexte sur la migration que je planifie et teste lentement. J’ai finalement essayé l’importateur Drupal vendredi dernier sur un VPS de test en utilisant une combinaison de ceci et ceci. L’importateur est toujours en cours au moment où j’écris ceci, donc je n’ai pas encore pu tester la fonctionnalité du site de test, mais il est sur le point de se terminer bientôt.
Le plus gros problème que je rencontre est une « valeur de clé dupliquée » sur 8 nœuds apparemment aléatoires (l’équivalent des sujets dans Discourse) sur environ 80 000 nœuds au total. Ce sont les numéros nid spécifiques au cas où il y aurait un bug mathématique étrange de type Y2K :
42081, 53125, 57807, 63932, 66756, 76561, 78250, 82707
La même erreur se produit toujours sur les mêmes nid lors de la réexécution de l’importateur :
Traceback (most recent call last):
19: from script/import_scripts/drupal.rb:537:in `<main>'
18: from /var/www/discourse/script/import_scripts/base.rb:47:in `perform'
17: from script/import_scripts/drupal.rb:39:in `execute'
16: from script/import_scripts/drupal.rb:169:in `import_forum_topics'
15: from /var/www/discourse/script/import_scripts/base.rb:916:in `batches'
14: from /var/www/discourse/script/import_scripts/base.rb:916:in `loop'
13: from /var/www/discourse/script/import_scripts/base.rb:917:in `block in batches'
12: from script/import_scripts/drupal.rb:195:in `block in import_forum_topics'
11: from /var/www/discourse/script/import_scripts/base.rb:224:in `all_records_exist?'
10: from /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3.1/lib/active_record/transactions.rb:209:in `transaction'
9: from /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3.1/lib/active_record/connection_adapters/abstract/database_statements.rb:316:in `transaction'
8: from /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3.1/lib/active_record/connection_adapters/abstract/transaction.rb:317:in `within_new_transaction'
7: from /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `synchronize'
6: from /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `handle_interrupt'
5: from /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `block in synchronize'
4: from /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `handle_interrupt'
3: from /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3.1/lib/active_record/connection_adapters/abstract/transaction.rb:319:in `block in within_new_transaction'
2: from /var/www/discourse/script/import_scripts/base.rb:231:in `block in all_records_exist?'
1: from /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/pg.rb:56:in `exec'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/pg.rb:56:in `exec': ERROR: duplicate key value violates unique constraint "import_ids_pkey" (PG::UniqueViolation)
DETAIL: Key (val)=(nid:42081) already exists.
20: from script/import_scripts/drupal.rb:537:in `<main>'
19: from /var/www/discourse/script/import_scripts/base.rb:47:in `perform'
18: from script/import_scripts/drupal.rb:39:in `execute'
17: from script/import_scripts/drupal.rb:169:in `import_forum_topics'
16: from /var/www/discourse/script/import_scripts/base.rb:916:in `batches'
15: from /var/www/discourse/script/import_scripts/base.rb:916:in `loop'
14: from /var/www/discourse/script/import_scripts/base.rb:917:in `block in batches'
13: from script/import_scripts/drupal.rb:195:in `block in import_forum_topics'
12: from /var/www/discourse/script/import_scripts/base.rb:224:in `all_records_exist?'
11: from /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3.1/lib/active_record/transactions.rb:209:in `transaction'
10: from /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3.1/lib/active_record/connection_adapters/abstract/database_statements.rb:316:in `transaction'
9: from /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3.1/lib/active_record/connection_adapters/abstract/transaction.rb:317:in `within_new_transaction'
8: from /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `synchronize'
7: from /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `handle_interrupt'
6: from /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `block in synchronize'
5: from /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `handle_interrupt'
4: from /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activerecord-7.0.3.1/lib/active_record/connection_adapters/abstract/transaction.rb:319:in `block in within_new_transaction'
3: from /var/www/discourse/script/import_scripts/base.rb:243:in `block in all_records_exist?'
2: from /var/www/discourse/script/import_scripts/base.rb:243:in `ensure in block in all_records_exist?'
1: from /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/pg.rb:56:in `exec'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/pg.rb:56:in `exec': ERROR: current transaction is aborted, commands ignored until end of transaction block (PG::InFailedSqlTransaction)
La seule façon que j’ai trouvée pour qu’il continue a été de modifier les conditions SQL :
...
LEFT JOIN node_counter nc ON nc.nid = n.nid
WHERE n.type = 'forum'
AND n.status = 1
AND n.nid != 42081
AND n.nid != 53125
AND n.nid != 57807
AND n.nid != 63932
AND n.nid != 66756
AND n.nid != 76561
AND n.nid != 78250
AND n.nid != 82707
LIMIT #{BATCH_SIZE}
OFFSET #{offset};
...
J’ai inspecté le premier nœud échoué ainsi que les nid précédents et suivants de chaque côté dans la base de données Drupal source, et je ne vois rien de mal. Le nid est défini comme clé primaire et il a AUTO_INCREMENT, et le site Drupal d’origine fonctionne bien, donc il ne peut y avoir aucun problème fondamental avec l’intégrité de la base de données source.
Outre le bug ci-dessus, voici les limitations que je rencontre avec le script :
-
Permaliens : Il semble que le script d’importation créera des permaliens pour les anciennes URL de nœuds
example.com/node/XXXXXXX. Mais je dois également maintenir des liens vers des commentaires spécifiques dans ces nœuds, qui ont le format :example.com/comment/YYYYYYY#comment-YYYYYYY(YYYYYYYest le même dans les deux occurrences). Le schéma d’URL de Drupal n’inclut pas l’ID du nœud auquel le commentaire est associé, alors que Discourse le fait (example.com/t/topic-keywords/XXXXXXX/YY), ce qui semble être une complication majeure. -
Limitations des noms d’utilisateur : Drupal autorise les espaces dans les noms d’utilisateur. Je comprends que Discourse ne le fait pas, du moins il ne permet pas aux nouveaux utilisateurs d’en créer de cette façon. Ce post suggère que l’importateur « convertira » automatiquement les noms d’utilisateur problématiques, mais je ne vois aucun code pour cela dansMise à jour : En fait, il semble que Discourse ait géré cela automatiquement de manière correcte./import_scripts/drupal.rb. -
Utilisateurs bannis : Il semble que le script importe tous les utilisateurs, y compris les comptes bannis. Je pourrais probablement ajouter une condition assez facilement à la sélection SQL
WHERE status = 1pour n’importer que les comptes d’utilisateurs actifs, mais je ne suis pas sûr que cela causerait des problèmes avec la sérialisation des enregistrements. Par-dessus tout, je préférerais garder ces noms de comptes précédemment bannis avec leurs adresses e-mail associées bloqués en permanence afin que les mêmes utilisateurs problématiques ne s’inscrivent pas à nouveau sur Discourse. -
Champs de profil utilisateur : Quelqu’un sait-il s’il existe un exemple de code dans l’un des autres importateurs pour importer des champs d’informations personnelles à partir des profils de comptes utilisateurs ? J’ai un seul champ de profil (« Lieu ») que je dois importer.
-
Avatars (pas Gravatars) : Il semble assez étrange qu’il y ait du code dans l’importateur Drupal pour importer les Gravatars mais pas pour les images d’avatar de compte local, beaucoup plus couramment utilisées.
-
Messages privés : Presque tous les forums Drupal 7 utiliseront probablement le module tiers privatemsg (il n’y a pas de fonctionnalité officielle de PM Drupal). L’importateur ne prend pas en charge l’importation des PM. Dans mon cas, je dois en importer environ 1,5 million.
Merci d’avance pour votre aide et pour avoir rendu le script d’importation Drupal disponible.
C’était probablement plus de 15 ou 20 heures après que tu m’aies mis sur la bonne voie avec la requête SQL.