Lors de l’importation de fichiers mbxs, je rencontre une erreur indiquant que le message parent n’existe pas, alors qu’il semble bien être présent dans la base de données, index.db.
Voici l’erreur :
Le message parent 9205270657.AB03850@ben.dciem.dnd.ca n’existe pas. Ignorance de 9206031720.AA22567@ben.dciem.dnd.ca : UN APPEL À L’AIDE
Et voici l’entrée de la base de données :
Avez-vous des suggestions sur la raison de cet échec ?
Peut-être que l’ordre de tri est incorrect car vous regroupez les e-mails par sujet ? Cela vaut peut-être la peine d’investiguer. Les messages sont uniquement triés par Subject et par l’ordre des e-mails dans le fichier mbox.
Êtes-vous vraiment sûr de devoir regrouper les e-mails par sujet ? À en juger par votre capture d’écran, il semble que les e-mails possèdent également des en-têtes Message-ID, In-Reply-To et References corrects.
Merci. En examinant la table email_order, il semble qu’elles soient dans le bon ordre :
| msg_id | rowid |
|---|---|
| 9205270657.AB03850@ben.dciem.dnd.ca | 874 |
| 9206031720.AA22567@ben.dciem.dnd.ca | 875 |
Y aurait-il autre chose qui empêche l’importation de ces messages parents ?
Lors de la première importation, il semblait qu’il n’y avait aucun regroupement. Je pense que le problème vient du fait que les réponses sont adressées à la liste de diffusion plutôt qu’à l’expéditeur d’origine. De plus, certains messages ne possèdent pas ces champs du tout, car l’archive a été constituée manuellement sur une période de 28 ans, de manière plutôt désordonnée, avec différentes versions d’Eudora.
Peut-être que l’importation du message parent échoue ? Y a-t-il eu une erreur ? Il est difficile de déterminer pourquoi le message n’est pas trouvé. Je suis désolé, mais je pense que vous devrez déboguer cela vous-même en modifiant le code Ruby du script d’importation.
Non, je ne pense pas qu’il y ait eu d’erreur.
D’accord, même si je ne connais pas bien Ruby ni le script d’importation, je pourrais peut-être essayer.
Pourriez-vous me dire quels scripts examiner et où ils se trouvent ? « Déboguer » signifie-t-il ajouter des instructions d’impression ou existe-t-il des fonctionnalités plus sophistiquées ?
Bon, j’ai ajouté quelques débogages par puts dans map_first_post
def map_first_post(row)
puts "Mapping parent #{row['msg_id']} #{row['subject'][0..40]}"
mapped = map_post(row)
mapped[:category] = category_id_from_imported_category_id(row['category'])
mapped[:title] = row['subject'].strip[0...255]
mapped
puts "Mapped message #{row['msg_id']} #{row['subject'][0..40]}"
end
def map_reply(row)
parent = @lookup.topic_lookup_from_imported_post_id(row['in_reply_to'])
if parent.blank?
puts "Parent message #{row['in_reply_to']} doesn't exist. Skipping #{row['msg_id']}: #{row['subject'][0..40]}"
return nil
end
mapped = map_post(row)
mapped[:topic_id] = parent[:topic_id]
mapped
end
Ces messages s’affichent correctement et suggèrent que le parent est bien mappé (importé ?)
873 / 65936 ( 1.3%) [3895 items/min]
Mapping parent 9205270657.AB03850@ben.dciem.dnd.ca A CALL FOR HELP
Mapped message 9205270657.AB03850@ben.dciem.dnd.ca A CALL FOR HELP
874 / 65936 ( 1.3%) [3900 items/min]
Parent message 9205270657.AB03850@ben.dciem.dnd.ca doesn’t exist. Skipping 9206031720.AA22567@ben.dciem.dnd.ca: A CALL FOR HELP
Donc, je ne vois pas pourquoi le parent est vide dans map_reply. La seule chose que je remarque, c’est que les numéros (873/874) sont inférieurs d’une unité à l’rowid ci-dessus.
Mais je ne pense pas pouvoir aller plus loin car je ne sais pas ce que fait @lookup.topic_lookup_from_imported_post_id, et il est très fastidieux de modifier avec vi et de relancer l’import, chaque cycle prenant environ 30 minutes.
C’est dans base.rb dans le même répertoire. Et il fait exactement ce que le nom de la fonction suggère : il recherche le topic_id en trouvant l’import_id (que je suppose être l’ID du message dans ce cas) dans un champ personnalisé du topic (ou peut-être un champ personnalisé du post ?).
C’est mieux que ceux qui prennent une semaine. 
(Parfois, vous pouvez faire en sorte que le script d’import n’importe que les éléments que vous essayez de déboguer ; la manière de le faire est laissée en exercice pour le lecteur.)
Vous pouvez essayer de consulter la base de données pour voir si le message parent est bien importé et s’il possède un champ personnalisé de topic/post import_id.
Où regarde-t-elle ? Le topic_id est-il le sujet ?
Par « base de données », voulez-vous dire index.db ? Par « importé », voulez-vous dire entré dans la table email de index.db ? Oui, il s’y trouve. Mais il n’y a pas de colonne nommée « import_id ».
Par base de données, j’entends la base de données Discourse. L’ID d’importation se trouve dans les tables topic_custom_field et post_custom_field.
Aha !
J’ai importé le plugin Data Explorer et examiné la base de données Discourse. J’ai constaté que l’import_id du message parent était présent dans les tables topic_custom_field et post_custom_field. De plus, le message existait bien.
Cependant, il avait été supprimé. Donc, je suppose que j’ai reçu l’erreur « le message parent n’existe pas » parce que l’importation cherchait dans la base de données Discourse plutôt que dans index.db. Il aurait été utile d’obtenir un message d’erreur indiquant que le message avait été supprimé.
Quoi qu’il en soit, je pense que cela s’est produit car, lors d’un premier test, j’avais supprimé le premier lot (petit) de messages importés. Je croyais avoir restauré l’état antérieur à ce point, mais manifestement pas.
La bonne nouvelle, c’est que cela ne concerne que mon serveur de test et que je ne devrais pas rencontrer ce problème lors de l’importation sur le serveur en production.
Merci pour vos indications.
Pourquoi ? Par qui ?
Ce n’est pas quelque chose qui se produit lors d’une importation.
Cela semble correct. Et supprimer des messages ne les efface pas, mais les marque comme supprimés.