This library consider add column with default operation is unsafe operation, it was actual for old versions that rewrite whole table to add default. New postgres versions changes only metadata so this operation is fast and can be considered as safe except cases when column added with default and not null that is not safe operation in case of django that use default only for filling data and drop db default after migration. Also adding column with default is much efficient operation than adding column and fulfill data manually.
In django 5.0 new db_default were added that assume add column with default (using db_default) is safe both for adding column with null and not null.
So in this MR whole approach to work with defaults were changed:
add column default null - safe operation, after migration null values can be presented in db
add column default not null is unsafe operation
add column db_default both null and not null - safe operation, after migration no nulls can be presented in db
add column default for django < 5.0 and ZERO_DOWNTIME_MIGRATIONS_KEEP_DEFAULT=True - safe operation, after migration no nulls can be presented in db, provide same behavior as db_default
This library consider add column with default operation is unsafe operation, it was actual for old versions that rewrite whole table to add default. New postgres versions changes only metadata so this operation is fast and can be considered as safe except cases when column added with default and not null that is not safe operation in case of django that use default only for filling data and drop db default after migration. Also adding column with default is much efficient operation than adding column and fulfill data manually.
In django 5.0 new db_default were added that assume add column with default (using db_default) is safe both for adding column with null and not null.
So in this MR whole approach to work with defaults were changed:
ZERO_DOWNTIME_MIGRATIONS_KEEP_DEFAULT=True- safe operation, after migration no nulls can be presented in db, provide same behavior asdb_defaultMore details described in https://github.com/tbicr/django-pg-zero-downtime-migrations/issues/62
changes:
ADD COLUMN DEFAULT NULLto safe operation for code defaultADD COLUMN DEFAULT NOT NULLto safe operation fordb_defaultin django 5.0+ZERO_DOWNTIME_MIGRATIONS_KEEP_DEFAULTsettings and changedADD COLUMN DEFAULT NOT NULLwith this settings to safe operation for django<5.0