مرحباً، أنا ومجموعتي من الأغبياء المجانين على وشك الانتهاء من ترحيل منتدى Vbulletin3 الخاص بنا إلى Discourse بعد كتابة نص مخصص نجح أخيرًا في ترحيل جميع الردود البالغ عددها 21 مليونًا من قاعدة البيانات الأصلية إلى Discourse.
الآن، لدينا مشكلة الروابط إلى المواضيع/الردود المكتوبة في الردود نفسها.
في الترحيل الذي كتبناه، نكتب تعيينًا لمعرفات المواضيع والمنشورات “القديمة” وما تقابلها في Discourse.
على سبيل المثال:
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
ما كنت أفكر فيه الآن هو إضافة بسيطة تعترض الروابط إلى تنسيق المنتدى القديم وتحولها مع الإشارة إلى الموضوع/الرد الجديد.
سيؤدي إلى تشغيل بحث استعلام باستخدام topics_custom_field للقيمة 123456، والعثور على topic_id في Discourse، ثم الاستعلام عن جدول topic_links بهذا المعرف والعثور على url. أخيرًا، استبداله في المنشور على جانب العميل (بافتراض استخدام JavaScript لمعالجة المحتوى).
شيء مشابه للمنشورات.
ومع ذلك، لا يمكنني العثور على أي مثال جيد لكيفية البدء في إنشاء شيء كهذا لـ Discourse.
هل يمكن لأحد أن يعطيني بعض التلميحات أو الأمثلة أو الإضافات التي تقوم بشيء مماثل (التحقق من الردود بحثًا عن سلسلة فرعية معينة واستبدالها، الاستعلام عن واجهة برمجة التطبيقات؟ قاعدة البيانات؟ للحصول على قيمة لاسترداد قيمة أخرى؟).
عندما نقوم بترحيل محتوى الرد، على سبيل المثال: https://oldforum.something.com/showthread.php?t=123456 لا يعرف ما هو id الموضوع الذي سيكون له على discourse… أليس كذلك؟
للأسف لا يمكننا استخدام هذا الكود لأن الاستيراد يستغرق وقتًا طويلاً لاستيراد 20 مليون مشاركة ولا يعمل الاستيراد المجمع. هناك أجزاء مفقودة.
لهذا السبب اضطررنا إلى كتابة نص الاستيراد الخاص بنا. يقوم بكل شيء (رسائل خاصة، مستخدمون، مجموعات مستخدمين، فئات، مواضيع، ردود) في حوالي 6 ساعات باستخدام 4 أنوية و 8 جيجابايت من ذاكرة الوصول العشوائي ولكننا لاحظنا أننا نفتقد الروابط الدائمة
كنا نحاول تجنب تكرار جميع الردود البالغ عددها 20 مليونًا مرة أخرى ولكن أدركنا أن الحلول البديلة (المكون الإضافي، إعادة توجيه nginx، إلخ) ستكون معقدة للغاية أو تعتمد على عوامل خارجية من شأنها أن تجعلها حلاً غير مكتمل، لذلك، سنقوم ببساطة بتكرار الردود مرة أخرى ومعالجة الروابط الدائمة. سيضيف ذلك بعض الوقت إلى الترحيل ولكن نأمل ألا يكون كثيرًا.
كل شيء آخر “مُعد” أثناء التنقل لأننا نعرف ما يجب تحويله من “خام” إلى HTML.
بالنسبة للروابط الدائمة، لا يمكننا فعل ذلك لأنه إذا تمت إضافة رابط دائم مع تعديل، فقد يشير إلى موضوع لم تتم معالجته بعد (معرف موضوع أعلى) ولن يتم العثور على تلك الموضوعات في جدول topics_custom_field في وقت معالجتها.
يتم استيراد المواضيع وجميع ردودها مع الحفاظ على معرفات المواضيع من الأصغر إلى الأكبر من قاعدة بيانات vbulletin. هذا يعني أيضًا أننا نستورد بالترتيب الزمني.
ومع ذلك، هذا من شأنه أن يؤدي إلى الاعتقاد بأنه إذا وجدت أي إشارة إلى موضوع آخر، فسيكون دائمًا لموضوع موجود بالفعل.
ولكن هناك حالات لا يكون فيها هذا صحيحًا، إليك بعض الأمثلة:
تقسيم الموضوع مع تعليق أدى إلى التقسيم. سيكون التقسيم بمعرف أعلى ولكنه موجود في موضوع بمعرف أقل.
التحرير للقراء المستقبليين حيث تشير مشاركات المواضيع القديمة إلى مواضيع أحدث.
لذا، نعم، بينما يتم إنشاء TopicCustomField وملؤه أثناء تقدم الاستيراد، كما هو موضح في الموضوع الأول، فإنه ليس موثوقًا به للقيام بذلك “أثناء التنقل” لأنه لا يمكنك التأكد من العثور دائمًا على التطابق الصحيح بين المعرفات.
هناك حاجة إلى تمريرة أخرى بعد اكتمال الاستيراد بالكامل.
بخصوص TopicCustomField.each do |tcf|، لست متأكدًا مما سيفعله الجزء tcf. لغة Ruby ليست لغة تعلمتها. النص البرمجي الخاص بنا مكتوب بلغة C# لأن غالبية الأشخاص الذين عرضوا العمل عليه يستخدمونها بالفعل في العمل.
