#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         |   Keywords:
 Triage Stage:  Unreviewed     |  Has patch:  0
Easy pickings:  0              |      UI/UX:  0
-------------------------------+--------------------
 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 a dependency for the
 migration I actually intended to create. There doesn't appear to be a way
 to avoid this.

 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?

--
Ticket URL: <https://code.djangoproject.com/ticket/23581>
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.5d8491eae84d8a4793e328a47ec57a10%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to