Changes between Initial Version and Version 1 of Ticket #28273, comment 2
- Timestamp:
- Jun 5, 2017, 9:33:37 PM (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #28273, comment 2
initial v1 2 2 > Can't you accomplish this by adding the column as `null=True`, populating the values, then changing the column to `null=False` (similar to the [https://docs.djangoproject.com/en/dev/howto/writing-migrations/#migrations-that-add-unique-fields Migrations that add unique fields] howto)? I believe defaults should only be added when adding non-nullable columns -- if that behavior were changed, how would the non-null constraint be avoided? 3 3 4 Because we want to deploy without downtime, we already deploy fields with {{{null=True}}}, and add a backfill later. The issue I'm trying to point out here is that with `default=a_value` set (even with `null=True`) we still hit an issue because Postgres backfills defaults into existing rows when a column is added (even if the column is nullable). I am not aware of how other DB backends handle adding a column with `DEFAULT` + `NULL` set.4 Because we want to deploy without downtime, we already deploy fields with {{{null=True}}}, and add a backfill later. The issue I'm trying to point out here is that with `default=a_value` set (even with `null=True`) we still hit an issue because Postgres backfills defaults into existing rows when a column is added (even if the column is nullable). While normally Django doesn't use DB-level defaults, for the `AddField` operation it `does` add a default in the `ADD COLUMN` command if a default exists in the migration operation (and then remove it immediately, as seen in the SQL I posted earlier). I am not aware of how other DB backends handle adding a column with `DEFAULT` + `NULL` set. 5 5 6 6 Our conclusion is that any `AddField` with a `default` set cannot be accomplished without downtime in a production system (similar to a non-null field), so we've written the following check for our migrations: