#23581: Changing model field choices results in spurious migrations
-------------------------------+--------------------------------------
Reporter: john_scott | Owner: nobody
Type: Uncategorized | Status: new
Component: Migrations | Version: 1.7
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Description changed by john_scott:
Old description:
> Consider a simple model:
>
> {{{#!python
> from django.db import models
>
> CHOICES = (
> ('1', '1'),
> )
>
> class BasicModel(models.Model):
> choices = models.CharField(choices=CHOICES, max_length=100)
> }}}
>
> If CHOICES is changed e.g. CHOICES += (('2', '2'),), then
> `makemigrations` insists on creating a new migration for this change.
> However, the migration appears to mostly be a no-op. `sqlmigrate` on
> PostgreSQL shows:
> {{{
> BEGIN;
> ALTER TABLE "core_basicmodel" ALTER COLUMN "choices" DROP DEFAULT;
>
> COMMIT;
> }}}
>
> Which is slightly strange since the initial migration never set a
> DEFAULT, so there is nothing to DROP.
>
> I first noticed this working with django-cms (see
> https://github.com/divio/django-cms/issues/3479). In some cases when I
> attempt to make a migration for an unrelated app, `makemigrations` will
> forcefully create a migration for the `cms` app because the
> settings.CMS_TEMPLATES choices have changed. It then makes this
> automatically created migration (which is output in the virtualenv e.g.
> `env/src/django-cms/cms/migrations_django`) a dependency for the
> migration I actually intended to create. There doesn't appear to be a way
> to avoid this. This means I now have a migration I actually need for one
> of my apps that is completely dependent on me creating a migration for a
> third party app, which I don't directly control, resulting in migrations
> that are broken for other developers.
>
> This can also happen when the choices differ in development vs
> deployment, Django will complain:
> {{{
> Your models have changes that are not yet reflected in a migration, and
> so won't be applied.
> Run 'manage.py makemigrations' to make new migrations, and then re-run
> 'manage.py migrate' to apply them.
> }}}
> So far this seems to mostly be harmless if slightly confusing/annoying. I
> am not familiar with the migration internals, but since 'choices' isn't
> used (at least not on PostgreSQL) to make any actual alterations to the
> database shouldn't it ignore this attribute?
New description:
Consider a simple model:
{{{#!python
from django.db import models
CHOICES = (
('1', '1'),
)
class BasicModel(models.Model):
choices = models.CharField(choices=CHOICES, max_length=100)
}}}
If CHOICES is changed e.g. CHOICES += (('2', '2'),), then `makemigrations`
insists on creating a new migration for this change. However, the
migration appears to mostly be a no-op. `sqlmigrate` on PostgreSQL shows:
{{{
BEGIN;
ALTER TABLE "core_basicmodel" ALTER COLUMN "choices" DROP DEFAULT;
COMMIT;
}}}
Which is slightly strange since the initial migration never set a DEFAULT,
so there is nothing to DROP.
I first noticed this working with django-cms (see https://github.com/divio
/django-cms/issues/3479). In some cases when I attempt to make a migration
for an unrelated app, `makemigrations` will forcefully create a migration
for the `cms` app because the settings.CMS_TEMPLATES choices have changed.
It then makes this automatically created migration (which is output in the
virtualenv e.g. `env/src/django-cms/cms/migrations_django`) a dependency
for the migration I actually intended to create. There doesn't appear to
be a way to avoid this. This means I now have a migration I actually need
for one of my apps that is completely dependent on me creating a migration
for a third party app, which I don't directly control, resulting in
migrations that are broken for other developers.
This can also happen when the choices differ in development vs deployment,
Django will complain:
{{{
Your models have changes that are not yet reflected in a migration, and
so won't be applied.
Run 'manage.py makemigrations' to make new migrations, and then re-run
'manage.py migrate' to apply them.
}}}
I am not familiar with the migration internals, but since 'choices' isn't
used (at least not on PostgreSQL) to make any actual alterations to the
database shouldn't it ignore this attribute?
--
--
Ticket URL: <https://code.djangoproject.com/ticket/23581#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/068.c534786464920a097c98f760f5a24090%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
