يجب أن تأخذ عملية ترحيل الإعدادات في الاعتبار GlobalSettings

لقد رأيت مؤخرًا بعض عمليات ترحيل الإعدادات (آخرها كان إزالة automatic_backups_enabled) حيث يستخدم الترحيل قيم قاعدة البيانات فقط لحساب قيمة جديدة. هذا يتجاهل أي إعدادات تم إجراؤها في discourse.conf عبر app.yml.

الكود:

INSERT INTO site_settings (name, data_type, value, created_at, updated_at)
      SELECT 'backup_frequency', 3, NULL, 'NOW()', 'NOW()'
      WHERE EXISTS (
        SELECT 1
        FROM site_settings
        WHERE name = 'automatic_backups_enabled'
        AND VALUE = 'f'
        LIMIT 1
      )
      ON CONFLICT (name) DO UPDATE SET value = NULL, updated_at = 'NOW()';

والذي يتجاهل automatic_backups_enabled = false في discourse.conf ونتيجة لذلك، لا يبقي النسخ الاحتياطي معطلاً عند وجود هذا الإعداد.

لقد أبحر هذا السفينة المحددة، ولكن قد يكون من الجيد أن نتذكر أن هذا النمط يسبب مشاكل مع الإعدادات التي يتم تجاوزها عالميًا.

4 إعجابات

أعتقد أنه في هذه الحالة، في المستقبل يجب أن ننظر إلى DISCOURSE_... في Env أثناء عمليات الترحيل هذه.

@ted أعتقد أنه من المفيد المتابعة بأثر رجعي لأنه سيضع النمط للمضي قدمًا.

لست متأكدًا مما إذا كان GlobalSetting محملًا أم أنه شيء نريد الاعتماد عليه، ولكن إلقاء نظرة خاطفة على

ENV['DISCOURSE_AUTOMATIC_BACKUPS_ENABLED'] وجعله يفوز على الإعداد في قاعدة البيانات هو على الأرجح أمر حكيم.

@tgxworld / @ted ربما يجب أن نضيف “مساعد ترحيل” لهذا؟

على سبيل المثال:

MigrationHelper.get_setting('abc')
MigrationHelper.set_setting('abc', '123')
3 إعجابات

نعم، يتم تحميل GlobalSetting أثناء عمليات الترحيل :+1:

لا أعتقد أنك تريد الاعتماد على متغير بيئة وقت الإنشاء أيضًا؟ هذا يجعل من الصعب فصل خطوة متغير البيئة إلى discourse.conf وخطوة نشر الحاوية الفعلية. في عالمي الآخر (PHP/Laravel) يُنظر إلى هذا على أنه نمط غير مرغوب فيه.

إعجاب واحد (1)