ربما يكون ترتيب الفرز خاطئًا لأنك تقوم بتجميع رسائل البريد الإلكتروني حسب الموضوع؟ قد يستحق الأمر التحقيق. تُرتَّب الرسائل فقط حسب الموضوع وبنظام ترتيب الرسائل داخل ملف mbox.
هل أنت متأكد حقًا من حاجتك لتجميع رسائل البريد الإلكتروني حسب الموضوع؟ بناءً على لقطة الشاشة الخاصة بك، يبدو أن رسائل البريد الإلكتروني تحتوي على Message-ID صحيح بالإضافة إلى رؤوس In-Reply-To و References.
شكرًا لك. عند النظر إلى جدول email_order، يبدو أنها مرتبة بالترتيب الصحيح:
msg_id
rowid
9205270657.AB03850@ben.dciem.dnd.ca
874
9206031720.AA22567@ben.dciem.dnd.ca
875
هل يمكن أن يكون هناك شيء آخر يفشل في استيراد هذه الرسائل الأصلية؟
عندما قمت بالاستيراد الأول، بدا وكأنه لا يوجد أي تجميع على الإطلاق. أعتقد أن المشكلة تكمن في أن الردود موجهة إلى قائمة البريد الإلكتروني بدلاً من المرسل الأصلي. أيضًا، لا تحتوي بعض الرسائل على هذه الحقول على الإطلاق، حيث تم تجميع الأرشيف يدويًا على مدار 28 عامًا بطريقة عشوائية نسبيًا مع إصدارات مختلفة من Eudora.
ربما يفشل في استيراد الرسالة الأصلية؟ هل حدث خطأ؟ من الصعب تحديد سبب عدم العثور على الرسالة. أنا آسف، لكني أظن أنك ستحتاج إلى تصحيح هذا بنفسك عن طريق تعديل كود Ruby الخاص بسكربت الاستيراد.
تعمل هذه الطباعة بشكل جيد وتشير إلى أن العنصر الأب تم تعيينه (أو استيراده).
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
لذلك، لا أرى سببًا لكون العنصر الأب فارغًا في دالة map_reply. الشيء الوحيد الذي ألاحظه هو أن الأرقام (873/874) أقل بواحد من rowid أعلاه.
لكنني لا أعتقد أنني يمكنني المضي قدمًا كثيرًا لأنني لا أعرف ما الذي تفعله الدالة @lookup.topic_lookup_from_imported_post_id، كما أن التعديل باستخدام vi وإعادة تشغيل الاستيراد عملية شاقة للغاية، حيث تستغرق كل دورة حوالي 30 دقيقة.
إنه موجود في ملف base.rb في نفس الدليل. وهو يقوم بالضبط بما يقترحه اسم الدالة، حيث يبحث عن معرف الموضوع (topic_id) عن طريق العثور على معرف الاستيراد (import_id) (الذي أفترض أنه معرف الرسالة في هذه الحالة) في حقل مخصص للموضوع (أو ربما حقل مخصص للرسالة؟).
هذا أفضل من تلك التي تستغرق أسبوعًا. (في بعض الأحيان يمكنك القيام ببعض الأمور لجعل سكريبت الاستيراد يستورد فقط الأشياء التي تحاول تصحيحها؛ ترك كيفية القيام بذلك كممارسة للقارئ.)
يمكنك محاولة النظر إلى قاعدة البيانات لمعرفة ما إذا كانت الرسالة الأصلية يتم استيرادها وما إذا كان لديها حقل مخصص للموضوع/الرسالة باسم import_id.
هل تقصد بـ ‘قاعدة البيانات’ ملف index.db؟ وهل تقصد بـ ‘تم استيراده’ إدخاله في جدول البريد الإلكتروني في index.db؟ نعم، هو موجود هناك. لكن لا يوجد عمود يُسمى ‘import_id’.
لقد قمت باستيراد إضافة مستكشف البيانات ونظرت في قاعدة بيانات discourse. اكتشفت أن import_id للرسالة الأصلية كان موجودًا في جداول topic_custom_field و post_custom_field. كما أن الرسالة كانت موجودة بالفعل.
لكن، تم حذفها. لذا، أعتقد أنني كنت أحصل على خطأ “الرسالة الأصلية غير موجودة” لأن الاستيراد كان يبحث في قاعدة بيانات discourse بدلاً من index.db. كان سيكون من الجيد الحصول على رسالة خطأ تفيد بأن المنشور قد تم حذفه.
على أي حال، أعتقد أن هذا حدث لأنه أثناء اختبار مبكر، قمت بحذف الدفعة الأولى (الصغيرة) من المنشورات المستوردة. ظننت أنني قد استعدت إلى ما قبل هذه النقطة، لكن من الواضح أنني لم أفعل.
الجيد في الأمر أن هذا ينطبق فقط على خادم الاختبار الخاص بي، ولا ينبغي أن أواجه هذه المشكلة أثناء الاستيراد على الخادم المباشر.