#23581: Migration shouldn't generate "DROP DEFAULT" SQL if no database changes
are
required
--------------------------------------+------------------------------------
Reporter: john_scott | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Migrations | Version: 1.7
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by andrewgodwin):
Because of the way the new migrations system works, every attribute needs
to be present in an AlterField in order to make sure it's represented in
the historical state when it comes time to do a RunPython command. The
only way around that particular implementation detail would be to use
SeparateDatabaseAndState to say "the database changes are <empty list>,
the state changes are <alter field>", but that's pointless once we fix the
bug here where spurious default alteration is sent - once that's fixed an
AlterField with no schema changes won't do anything to the database
anyway.
If django-cms is using settings to define choices then, as Shai suggests,
django-cms can edit their migration so that the choices attribute points
to that settings variable rather than being copied from it and then the
autodetector won't detect any changes. You can't do anything as a user
other than encourage them to fix their migrations. You could also fork
their migration tree and use MIGRATION_MODULES to point it to something
you control for now, but that's not a great solution.
This is just one of those pain points as people (and third party apps)
adapt to the new migrations - sorry about this, but there's no quick short
term fix, third parties just have to get used to crafting migrations along
with models. If you set any field attribute to something outside the scope
of model control (like a setting) you just have to point it to the same
thing in the resultant migration that makes that field and the
autodetector will be happy.
Subclassing fields and removing choices is a possible but very extreme
solution; that would only make sense for a field whose choices change
literally every time the application starts (e.g. they're randomised or
something), which is pretty rare from what I've seen (people who are
pulling choices from querysets at boot, for example, are probably doing it
wrong)
--
Ticket URL: <https://code.djangoproject.com/ticket/23581#comment:12>
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.a14f443f76a4719e03e3ffd000af37e6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
