Ho visto alcune migrazioni di impostazioni di recente (l’ultima è stata la rimozione di automatic_backups_enabled) in cui la migrazione utilizza solo valori del database per calcolare un nuovo valore. Ciò ignora qualsiasi impostazione effettuata in discourse.conf tramite app.yml.
Codice:
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()';
che ignora automatic_backups_enabled = false in discourse.conf e, di conseguenza, non mantiene i backup disabilitati quando tale impostazione è presente.
Questa specifica nave è salpata, ma potrebbe essere utile tenere presente che questo schema causa problemi con le impostazioni che vengono sovrascritte a livello globale.
Sì, GlobalSetting viene caricato durante le migrazioni
Non credo che tu voglia fare affidamento nemmeno su una variabile d’ambiente in fase di compilazione? Rende difficile separare il passaggio da variabile d’ambiente a discourse.conf e l’effettiva distribuzione del container. Nel mio altro mondo (PHP/Laravel) questo è visto come un anti-pattern.