diff options
Diffstat (limited to 'doc/development/database/avoiding_downtime_in_migrations.md')
| -rw-r--r-- | doc/development/database/avoiding_downtime_in_migrations.md | 9 |
1 files changed, 8 insertions, 1 deletions
diff --git a/doc/development/database/avoiding_downtime_in_migrations.md b/doc/development/database/avoiding_downtime_in_migrations.md index 25310554c24..6a819e9f6cd 100644 --- a/doc/development/database/avoiding_downtime_in_migrations.md +++ b/doc/development/database/avoiding_downtime_in_migrations.md @@ -316,6 +316,13 @@ Example migration: Changing column defaults is difficult because of how Rails handles values that are equal to the default. +NOTE: +Rails ignores sending the default values to PostgreSQL when writing records. It leaves this task to +the database. When migrations change the default values of the columns, the running application is unaware +of this change due to the schema cache. The application is then under the risk of accidentally writing +wrong data to the database, especially when deploying the new version of the code +long after we run database migrations. + If running code ever explicitly writes the old default value of a column, you must follow a multi-step process to prevent Rails replacing the old default with the new default in INSERT queries that explicitly specify the old default. @@ -381,7 +388,7 @@ when migrating a column in a large table (for example, `issues`). Background migrations spread the work / load over a longer time period, without slowing down deployments. -For more information, see [the documentation on cleaning up batched background migrations](batched_background_migrations.md#cleaning-up). +For more information, see [the documentation on cleaning up batched background migrations](batched_background_migrations.md#cleaning-up-a-batched-background-migration). ## Adding indexes |