# La migración de configuraciones debe tener en cuenta GlobalSettings
**URL:** https://meta.discourse.org/t/migrating-settings-should-take-globalsettings-into-account/379789
**Category:** Bug
**Created:** [22 Agosto, 2025 04:27 UTC](https://meta.discourse.org/t/migrating-settings-should-take-globalsettings-into-account/379789 "2025-08-22T04:27:21Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [22 Agosto, 2025 04:27 UTC](https://meta.discourse.org/t/migrating-settings-should-take-globalsettings-into-account/379789/1 "2025-08-22T04:27:21Z")
He visto algunas migraciones de configuración recientemente (la más reciente fue la eliminación de [automatic\_backups\_enabled](https://github.com/discourse/discourse/commit/f8bf51441e71166a3995c5b03d0075e4c9556191)) donde la migración utiliza solo valores de la base de datos para calcular un nuevo valor. Esto ignora cualquier configuración realizada en `discourse.conf` a través de `app.yml`.
Código:
```plaintext
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()';
```
lo que ignora `automatic_backups_enabled = false` en `discourse.conf` y, como resultado, no mantiene las copias de seguridad deshabilitadas cuando esa configuración está presente.
Este barco específico ya zarpó, pero podría ser útil tener en cuenta que este patrón causa problemas con las configuraciones que se anulan globalmente.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [24 Agosto, 2025 23:57 UTC](https://meta.discourse.org/t/migrating-settings-should-take-globalsettings-into-account/379789/2 "2025-08-24T23:57:29Z")
Supongo que en este caso, en el futuro deberíamos observar `DISCOURSE_...` en Env durante estas migraciones.
@ted Supongo que vale la pena hacer un seguimiento retroactivo porque establecerá el patrón para el futuro.
No estoy seguro de si GlobalSetting está cargado o si es algo en lo que queremos apoyarnos, pero echando un vistazo a
`ENV['DISCOURSE_AUTOMATIC_BACKUPS_ENABLED']` y haciendo que prevalezca sobre la configuración en la base de datos es probablemente lo más sensato.
@tgxworld / @ted ¿quizás deberíamos agregar un “ayudante de migración” para esto?
Por ejemplo:
```plaintext
MigrationHelper.get_setting('abc')
MigrationHelper.set_setting('abc', '123')
```
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [25 Agosto, 2025 06:29 UTC](https://meta.discourse.org/t/migrating-settings-should-take-globalsettings-into-account/379789/4 "2025-08-25T06:29:06Z")
> [@sam](#):
>
> No estoy seguro de si GlobalSetting está cargado o si es algo en lo que queremos apoyarnos, pero echando un vistazo a
> `ENV['DISCOURSE_AUTOMATIC_BACKUPS_ENABLED']`
Sí, GlobalSetting se carga durante las migraciones 👍
Tampoco creo que quieras depender de una variable de entorno en tiempo de compilación. Hace que sea difícil separar el paso de la variable de entorno a discourse.conf y el despliegue real del contenedor. En mi otro mundo (PHP/Laravel) esto se considera un anti-patrón.