هناك بعض الحالات التي يرغب فيها المستخدمون في الاحتفاظ بملفات مُحمَّلة في Discourse غير مرتبطة بشكل صارم بنماذج Discourse الموجودة وخصائصها التي تدعم التحميلات، أي تحميلات “مُبيَّضة” أوفانية.
على سبيل المثال، يريد بعض الأشخاص استخدام إضافة Custom Wizard لتحميل محتوى مرتبط بموضوع (وليس منشورًا بحد ذاته).
المشكلة تكمن في أن مهمة clean_up_uploads تحذف جميع التحميلات الأوفانية. تقتصر استثناءاتها على عناوين URL موجودة في إعدادات الموقع المحددة.
يمكنك بالطبع إيقاف تشغيل clean_up_uploads، أو زيادة clean_orphan_uploads_grace_period_hours، وهو ما أُجبر أحيانًا على فعله. لكن هذا ليس الحل الأمثل.
ربما توجد طريقة أخرى لـ “تبييض” التحميلات الأوفانية من خلال إضافة لم أرها بعد، ولكن إذا لم تكن موجودة، فسيكون من الرائع إضافة آلية للقيام بذلك ضمن عملية تنظيف التحميلات.
يسعدني إعداد طلب سحب (PR) في هذا الصدد، لكنني أتساءل عما إذا كان آخرون يرون أن هذه مشكلة تستحق المعالجة.
نعم، كنت أفكر في هذا. لم يعجبني كحل لأنني سأحتاج إلى إنشاء إعداد مختلف لكل ملف مرفق، وهو ما يبدو كإساءة استخدام لجدول site_settings.
كحل مؤقت، قبل نقل الجبل، هل تمانع لو قمت بإنشاء طلب سحب (PR) لإضافة استثناء إضافي لاستعلام “الاستثناءات” الكبير الذي يستخدم plugin_store_row مع plugin_name مثل whitelisted_orphan_upload_id؟
هذا الاستعلام بطيء بالفعل بشكل كبير، وأخشى أن إضافة ارتباط آخر هنا سيجعله مؤلمًا للغاية.
لست متأكدًا، لكن ربما نبدأ بإعداد جدول جديد في النواة لـ UploadReference(object_id, object_type, upload_id) والارتباط به، على الأقل سيكون ذلك رخيصًا، ثم يمكننا نقل البيانات إليه. هناك العديد من التحركات السهلة، فقط رفعات المنشورات ستكون محيرة… أكثر.
أعتقد أن هذه مهمة أفضّل أن يتولاها الفريق هنا، فهي دقيقة للغاية.
هل تقصد الوراثة من جدول واحد (single table inheritance) في Rails؟ [ActiveRecord::Inheritance] إنها مناسبة جدًا لعناصر المراجعة، لأن هناك منطقًا أساسيًا مشتركًا بينها جميعًا، بالإضافة إلى حقول إضافية.
لكن في هذه الحالة، يبدو أن المشكلة تكمن في أننا نضع معرفات التحميل (upload ids) في كل مكان، ولا نقوم بحذف التحميلات عند إزالتها؟
هل من غير الآمن حذف تحميل إذا أزاله المستخدم من ملفه الشخصي، نظرًا لأنه قد يُستخدم نفس بصمة SHA1 للتحميل في مكان آخر من التطبيق؟ إذا كان الأمر كذلك، فأعتقد أن اقتراح سام بإنشاء جدول UploadReference هو حل جيد.
إذا لم تُشارك التحميلات بهذه الطريقة أبدًا، فأعتقد أن الحل الأفضل هو حذفها عند تعيين هذه الحقول إلى NULL.
هذا بالضبط السبب الذي يجعلنا بحاجة إلى جدول UploadReference
في الواقع، أعتقد أن هذه مهمة ممتازة لتعلم المزيد عن البنية الداخلية لـ Discourse. قد تكون مهمة مناسبة لـ @cvx، بدءًا من أوائل أكتوبر. سنقوم ببعض البرمجة الزوجية للبدء بشكل صحيح وتقسيم المهمة إلى عدة مهام “صغيرة”.
أنا مهتم جداً بجدول UploadReference. نحن في موقف لدينا فيه الكثير من الرفع في الإضافات التي تُعتبر رفعاً يتيمًا. حلنا هو ببساطة إيقاف clean_up_uploads. تفحصت الأمر اليوم ووجدت أن لدينا الآن 10 جيجابايت من الرفع اليتيم الذي يحتاج إلى حذف يدوي عبر سكريبت يحدد أيضاً ما إذا كنا نشير إلى أي منها في إضافاتنا. حل مثل ذلك الذي نوقش هنا سيساعدنا كثيراً.
أيضًا، في نفس السياق. نحن نشير إلى بعض الملفات المرفقة في بعض الحالات باستخدام وسوم HTML فقط. يبدو أن هذا يتسبب في تعطيل معالجة هذه المنشورات، كما أن روابط أخرى مثل الروابط التشعبية لا يتم معالجتها بشكل صحيح. ألاحظ أن الملفات المرفقة تُشار إليها عادةً بطريقة من نوع upload://.png. سؤالي هو: أين يمكن العثور على السلسلة هذه؟ لا يبدو أنها مخزنة في الملف المرفق كما أستطيع ملاحظته.
