Enumerate and remove DEFAULT constraints #38
Conversation
SQL Server implements in-database DEFAULT conditions as constraints, and requires that they be explicitly dropped before allowing the related column to be removed. Extend introspection to detect these constraints and return them as a new constraint type. Make the schema editor read and remove these constraints when removing a column. Django doesn't generally use in-database DEFAULTs, but they can exist in legacy databases other tools have touched (for example old versions of South would accidentally leave defaults in place after a migration to make a nullable column non-nullable).
|
FYI, there are discussions going on now, on the django-developers mailing list, looking to add use of database defaults to Django. I would take a good look at the suggestions there to make sure you aren't going against the direction of evolution of Django. |
Hand merge of michiya#38 : When removing columns make sure we remove defaults (which Microsoft has deemed to be constraints).
|
FWIW Something like this PR may need to be done over on https://github.com/microsoft/mssql-django/ to support this |
|
Seems this has now been done in microsoft/mssql-django#313 |
SQL Server implements in-database DEFAULT conditions as constraints, and requires that they be explicitly dropped before allowing the related column to be removed. Extend introspection to detect these constraints and return them as a new constraint type. Make the schema editor read and remove these constraints when removing a column.
Django doesn't generally use in-database DEFAULTs, but they can exist in legacy databases other tools have touched. For example: old versions of South would accidentally leave defaults in place after a migration to make a nullable column non-nullable. This can cause unexpected migration failures trying to delete the column later on.