So for example we have a field:
{{{
name = models.CharField(max_length=255, null=True)
}}}
And we want to make it non-nullable. To make it so we perform two
migrations, firstly the state:
{{{
operations = [
# Plus whatever data migration is needed for the NULL values
migrations.SeparateDatabaseAndState(
state_operations=[
migrations.AlterField(
model_name='testmodel',
name='name',
field=models.CharField(max_length=255)
)
]
)
]
}}}
After all parts of the system have been updated with code that handles the
given field only in a non-nullable way, we can safely set it to NON NULL
in the database:
{{{
operations = [
migrations.SeparateDatabaseAndState(
database_operations=[
migrations.AlterField(
model_name='testmodel',
name='name',
field=models.CharField(max_length=255)
)
]
)
]
}}}
But the last migration doesn't actually perform any changes, the field
remains nullable in the database. This can be circumvented by using
migrations.RunSQL, but one can easily miss out the need to do that.
PostgreSQL in use: 9.6 official docker image.
Originally found for Django 1.8, reproduced for Django 2.1.7.
Didn't reproduce with SQLite.
--
Ticket URL: <https://code.djangoproject.com/ticket/30269>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* status: new => closed
* resolution: => invalid
Comment:
All the operations operate on the difference between the implicit previous
state and the one that applying the operation on it would generate and
`SeparateDatabaseAndState` behaves the same way.
What you are doing here by breaking the desired changes in two migrations
by creating an asymmetry between the project state and the database state.
When the second operation runs the state already has it's field altered by
the previous `SeparateDatabaseAndState` and thus the migration framework
considers your database operation as a noop.
In summary this is working as designed and performing the second operation
using `RunSQL` is the right approach if you want to effectively break this
in two migrations. A preferred way of ensuring no downtime for such field
alteration is usually to simply run such migrations once the code is
deployed instead.
--
Ticket URL: <https://code.djangoproject.com/ticket/30269#comment:1>