النمط هو استخدام حقل 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، سأكون مهتمًا برأيك في ما سبق أيضًا.