GlobalSettings を考慮して設定を移行する

バグ
1

最近、いくつかの設定移行（最も最近ではautomatic_backups_enabled の削除）を見てきましたが、これらの移行ではデータベースの値のみを使用して新しい値を計算しています。これは、app.yml を介して discourse.conf で行われた設定を無視します。

コード：

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()';

これは discourse.conf の automatic_backups_enabled = false を無視するため、その設定が存在する場合にバックアップが無効のままになりません。

この特定の船はすでに航海してしまいましたが、このパターンがグローバルにオーバーライドされた設定で問題を引き起こす可能性があることを念頭に置くと良いでしょう。

「いいね！」 4
2

この場合、将来的にこれらの移行中にEnvのDISCOURSE_...を確認する必要があると思います。

@ted これは遡ってフォローアップする価値があると思います。なぜなら、今後のパターンを確立するからです。

GlobalSettingがロードされているか、あるいは頼りにしたいものなのかはわかりませんが、
ENV['DISCOURSE_AUTOMATIC_BACKUPS_ENABLED']を調べて、DBの設定よりも優先させるのが賢明かもしれません。

@tgxworld / @ted これのための「移行ヘルパー」を追加すべきでしょうか？

例：

MigrationHelper.get_setting('abc')
MigrationHelper.set_setting('abc', '123')
「いいね！」 3
4

はい、GlobalSettingはマイグレーション中にロードされます :+1:

ビルド時の環境変数にも頼りたくないのではないでしょうか？環境変数をdiscourse.confに分離するステップと、実際のコンテナデプロイメントを分けるのが難しくなります。私の他の世界（PHP/Laravel）では、これはアンチパターンと見なされています。

「いいね！」 1