أود تقديم طلب سحب (PR) لإضافة دالة get_like إلى PluginStore.
ستقوم دالة get_like بجلب جميع السجلات لملحق معين، حيث يبدأ المفتاح بنفس الكلمة.
حالة الاستخدام
إذا كان لدى الملحق كيانان أو أكثر يريدان تخزينها، مثل التفاح والبرتقال، فسيتم تخزين البيانات على شكل apple_1، apple_2… وorange_1، orange_2 من ملحق باسم الفواكه.
لجلب جميع “البرتقال”، يمكن ببساطة استدعاء PluginStore.get_like(‘fruits’, ‘orange’) وما إلى ذلك.
ما رأي الفريق ومطوري الإضافات في هذا؟
لا أعتقد أنني احتجت شخصيًا إلى هذا النمط. هل رأيته في إضافات عامة، أم فقط في الإضافة التي تنشئها؟
أيضًا، كتابته ليست طويلة جدًا:
PluginStoreRow.where("plugin_name = 'fruits' AND key LIKE 'orange%')
أنصحك بإضافة دالة مساعدة أو فئة إلى الإضافة الخاصة بك إذا كنت تفعل ذلك بشكل متكرر. كما تأكد من وجود فهارس مناسبة لهذه الاستعلامات.
كنت أعمل على هذه الميزة لإضافة custom-wizards، وكنت أرغب في جلب جميع السحرة.
المفتاح المستخدم هو نص فريد لكل ساحر. تم التعامل مع هذه الحالة عن طريق جلب جميع الصفوف للإضافة وتصفيتها بناءً على value، وهو أمر مقبول لعدد صغير من السجلات، لكنه ليس مثاليًا لإضافة كبيرة. يبدو أن جدول plugin_store_rows مُصمم لتخزين بيانات شبيهة بالإعدادات للإضافة.
أعتقد شخصيًا أن هذا قد يفتح الباب لفكرة تخزين بيانات غير شبيهة بالإعدادات في جدول plugin_store_rows.
(سامحني إذا بدا ذلك غريبًا)
بشكل عام، أوصي بإنشاء جداولك الخاصة عبر عمليات الترحيل إذا لم يكن بالإمكان استعلام PluginStoreRow بالطريقة التي تريدها. يتم الآن القيام بذلك بشكل شائع في عدة إضافات ويعمل بشكل ممتاز!
أوه، لم أكن على علم بذلك. شكرًا جزيلاً لك.
النمط هو استخدام حقل key في جدول plugin_store_rows لتخزين كل من مساحة الاسم ومعرف فريد، أي:
<namespace>_<id>
يُلاحظ هذا النمط بشكل أقل في إضافات Discourse الأساسية هذه الأيام مع انخفاض عام في استخدام PluginStore، على سبيل المثال:
إضافة OAuth2 Basic استخدمتها لتخزين بيانات الحسابات المرتبطة حتى قمنا بنقلها إلى user_associated_accounts.
إضافة Poll استخدمتها قبل الانتقال إلى جدولها الخاص.
ومع ذلك، لا يزال هذا النمط مستخدمًا في بعض الأماكن، بما في ذلك قاعدة الكود الأساسية لـ Discourse نفسها، على سبيل المثال في نموذج Reviewables.
أنا أيضًا أستخدم هذا النمط في عدد من الإضافات.
السبب الرئيسي لاستخدام هذا النمط هو أن جدول plugin_store_rows يُستخدم بواسطة عدة إضافات (وبعض الخدمات الأساسية)، وبالتالي لا يمكن استخدام أعمدة التعريف، أي id وplugin_name، للتعريف داخليًا داخل كل نظام يستخدم PluginStore. لذلك، يُستخدم نظام قائم على السلاسل النصية في عمود key بدلاً من ذلك.
فيما يتعلق بتغيير هيكل قاعدة البيانات من داخل إضافة، ينشر @gdpelican منشورًا جيدًا حول هذا الموضوع:
شخصيًا، لا أزال حذرًا جدًا من القيام بذلك، حيث إن العمل على إضافة تابعة لطرف ثالث يعني أنك لا تملك التحكم في مساحة التسمية، أو ما إذا كانت الإضافة ستُزال، أو التغييرات المحتملة المتعارضة التي قد تُجرى على Discourse الأساسي.
كما يشير @gdpelican، يجب أن توفر طريقة لمستخدم الإضافة لإزالة تغييرات قاعدة البيانات إذا قام بإلغاء تثبيت الإضافة.
توفير طريقة للمستخدمين لتنظيف تغييرات قاعدة البيانات الخاصة بك إذا لم يعودوا يريدون الإضافة. قمت بذلك باستخدام مهمة rake.
أشعر أن هذا الأمر معقد جدًا لمعظم مستخدمي الإضافات ويشكل خطرًا إذا لم يكونوا على دراية بهذا التفصيل.
علاوة على ذلك، لم أجد حاجة حقيقية للخروج عن حدود PluginStore وCustomFields حتى الآن.
مع كل ما سبق، شخصيًا، سأؤيد إضافة طريقة جديدة على هذا المنوال في PluginStore، لأنني أجد هذا النمط مفيدًا.
@David، سأكون مهتمًا برأيك في ما سبق أيضًا.
كما ذكر @eviltrout، نحن نستخدم هجرات الجداول المخصصة في عدد من الإضافات حاليًا، وقد حققت نجاحًا كبيرًا. إن القدرة على فرض قيود قاعدة البيانات ساعدت في تحسين الأداء (عمليات البحث في أي عمود) وسلامة البيانات (من خلال الفهارس الفريدة). وقد أثبت هذان العاملان أهميتهما خاصة على نطاق بعض عملائنا المستضافين - وهو أمر لم أكن أعتبره حقًا قبل انضمامي إلى الفريق.
أول إضافة كبيرة عملت عليها كانت chat-integration، وقمت بتنفيذ ما يُعرف بـ “fake activerecord” معقد جدًا يعتمد على متجر الإضافات. وبالنظر إلى الوراء، كان من الأفضل بكثير استخدام جداول مخصصة، وقد أفكر في هجرة هذه الإضافة إلى هذا النهج في المستقبل.
أتفق معك عندما يتعلق الأمر بتعديل جداول النواة. إضافة أو تعديل أعمدة في جداول موجودة قد تكون لها عواقب غير مقصودة لاحقًا، وستظل موجودة حتى لو تم إلغاء تثبيت الإضافة. وأوصي بشدة بعدم القيام بذلك.
أما الجداول المخصصة، فمن ناحية أخرى، فهي منخفضة المخاطر نسبيًا. إذا تم إلغاء تثبيت الإضافة، فستظل هذه الجداول موجودة دون أي آثار جانبية سلبية (طالما أنك لا تُدخل أي قيود مفاتيح أجنبية). ترك البيانات مبعثرة ليس “أسوأ” من استخدام متجر الإضافات.
من حيث التنظيف، يمكننا النظر في توفير مهام rake تعكس هجرات الإضافات لتنظيف البيانات. ولكن بصراحة، لا أعتقد أن هذا سيستخدم كثيرًا. افتراضي هو أن الناس نادرًا ما يقومون بإلغاء تثبيت الإضافات، وعندما يفعلون ذلك، يفضلون الاحتفاظ بالبيانات في حالة رغبتهم في إعادة تثبيتها مرة أخرى.
بصفتي مؤلف ذلك الكود، ربما يجب أن أوضح الأمر قليلاً. معرّفات الأولوية هي ثوابت وليست بيانات علائقية. أوصي بشدة بعدم استخدام something_id عندما لا تكون المعرّفات معروفة مسبقًا. في هذه الحالة، يُنظر إلى كل أولوية على أنها كيان مفرد، وتصورّت أن أي جدول سأنشئه سيكون في الأساس نسخة طبق الأصل من PluginStore!