يبدو أن PluginStore سيكون أسهل طريقة لي لتنفيذ تذكر معرفات خيوط Slack للردود المتسلسلة، لكنني لاحظت أن الاستخدام الوحيد له في discourse-chat-integration بأكملها هو استخدام معزول؛ فلا شيء يستخدم فعليًا القيمة التي يتم البحث عنها.
هل يعني هذا أنه تم إهماله أم أنه يتم بطريقة أخرى فقط؟
سأقوم بتخزين قيمة واحدة كحد أقصى لكل موضوع، لذا يبدو هذا منخفضًا نسبيًا من حيث التباين، إذا نظرنا إلى الأمور بشكل عام. هل هذا معقول بالنسبة لـ PluginStore؟
إذا كنت تخزن قيمة واحدة كحد أقصى لكل موضوع، فقد يكون استخدام حقل مخصص للموضوع خيارًا أفضل لهذه الحالة الاستخدامية.
PluginStore هو مخزن بسيط من نوع المفتاح-القيمة (KV) يُستخدم للإضافات حيث يكون تباين البيانات مرتفعًا لدرجة تجعله غير مناسب لجدول الحقول المخصصة الحالي. خلال السنوات الأخيرة، نقوم بنقل الإضافات إلى جداول خاصة بها لتحسين موثوقية البيانات حيث يكون ذلك منطقيًا، كما فعلنا مع إضافة الاستطلاعات. لا يزال بإمكانك استخدامه إذا كان مناسبًا لحالتك الاستخدامية.
شكرًا لك، يبدو أن عليّ فعل ذلك. بما أنني جديد هنا، هل يمكنكم إعطائي مثالًا لحقل مخصص للمواضيع في إضافة ما لأتعلم منه دون أن أكون مصدر إزعاج؟ 
يستخدم مكون الإضافات الخاص بالتصويت حقول الموضوع المخصصة قليلاً، مثل ما هو موضح في discourse-topic-voting/plugin.rb at main · discourse/discourse-topic-voting · GitHub و https://github.com/discourse/discourse-voting/blob/master/app/jobs/onceoff/voting_ensure_consistency.rb#L53
أعتقد أن هذا يوجهني في الاتجاه الصحيح، شكرًا جزيلاً لك!
للمستخدم الجديد الذي يجد هذا النص، إليك بعض الأخطاء التي ارتكبتها عندما كنت مبتدئًا تمامًا في Ruby on Rails:
isolate_namespace جزء من النمط الذي يجب اتباعه، ولم أدرك أن الـ namespace يشير إلى namespace المسار وليس إلى شيء في قاعدة البيانات. هذا تسبب لي في مشاكل. topic.save!) أو حفظ الحقول المخصصة فقط (مثل topic.save_custom_fields).نعم، يحتوي مزيج HasCustomFields على بعض المزايا مثل save_custom_fields، والتحويل التلقائي للأنواع، وما إلى ذلك.
يمكننا أن نتخيل إزالة متجر الإضافات وحقول التخصيص على المدى الطويل واستبدالهما أو تعديلهما بنظام أكثر تقييدًا وتحكماً، إذ إنهما يسببان متاعب أكثر مما يفيدان.
المكان الوحيد الذي نستخدم فيه حقول التخصيص ونحتاجها حقًا في هذه الأيام هو للإشارة إلى المُسلسلات (serializers) بوجود معلومات “خاصة” في المنشور، أو في الحالات الاستثنائية عند تزيين 50% من منشورات النظام، حيث يمكن وضع البيانات هناك أيضًا.
حقول التخصيص مرنة للغاية وتواجه العديد من مشاكل التزامن.
أفضل طريقة لإضافة بيانات غنية هي أن يقوم إضافة بإنشاء الجداول التي يحتاجها ويمتلكها؛ وهذا يجب أن يكون أول ما تفعله. وإذا علقت بسبب مشاكل مثل N+1 وغيرها، فاستعن بحقول التخصيص للمساعدة في تجنبها.
واو، أليس من شأن ذلك أن يكسر أجزاء كبيرة من نظام الإضافات الحالي؟
كان مساهمتي في discourse-chat-integration (لدعم المواضيع، انظر الموضوع) تعتمد على الحقول المخصصة بناءً على النصيحة التي تلقيتها هنا.
كيف تنشئ عادةً النماذج والهجرات للإضافات؟ هل تستخدم مولد Rails الرئيسي وتنسخها إلى مجلد الإضافة؟ لقد قمت بإنشاء مولد للنماذج والهجرات ينشئ النماذج والهجرات مع بادئة خاصة بالإضافة. GitHub - spirobel/discourse at plugin_model_and_migrations · GitHub ربما يكون هذا مفيدًا للآخرين أيضًا. 
أوصي بالنظر في discourse-policy وإضافة الاستطلاعات للحصول على أمثلة حول كيفية إجراء عمليات الترحيل الخاصة بنا. هذا هو النمط الذي يجب عليك اتباعه.
ستحدث التغييرات تدريجيًا وسنقدم التوجيهات. لقد أدى النظام الحالي المعتمد بشكل كبير على متجر الإضافات وحقول التخصيص إلى حدوث عدد لا يحصى من المشاكل الأسبوعية الروتينية.
نظرت إلى إضافة الاستطلاعات وبناءً عليها أنشأت مولد نموذج للإضافات، وكذلك مولد هجرات هذا:
إذا فهمت الأمر بشكل صحيح، فإن أحد أسباب إنشاء متجر الإضافات في المقام الأول كان القلق من أنه إذا أنشأت الإضافات جداولها الخاصة، فقد تتصادم الأسماء. المولدات التي أنشأتها ستضيف بادئة لأسماء النماذج والهجرات باسم الإضافة. لقد قمت بإنشاء هذه المولدات بشكل أساسي لأن الهجرات تحتاج إلى أن تحتوي على رقم التاريخ في المقدمة لإنشاء ترتيب يمكن التنبؤ به. لهذا السبب لم أرغب في إنشائها يدويًا.
التعارض، رغم كونه مشكلة نظرية، لم يكن الدافع الرئيسي. بل كان الدافع الأكبر هو أن تشغيل عمليات الترحيل كان غير واضح إلى حد ما، وكنا نرغب في شيء لا يتطلب أي جهد يذكر. في هذه الأيام، أصبح إنشاء عمليات الترحيل في الإضافات أمرًا تافهًا؛ فكل ما عليك فعله هو إنشاء ملف في مجلد الترحيل.
ومع ذلك، لا يزال من الممكن حدوث تعارض في حقول المداخل المخصصة.