#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 john_scott):
Is there then a corresponding 'best practice' for how to handle this?
Again the issue is that Django is forcibly creating migrations for 3rd
party apps which for obvious reasons we do not control. We now have to
manually edit every migration we *do* want to create for our apps to make
sure it points to the last official djangoc-cms migration (since that is
the 'true' representation and present in all environments) rather than
whatever Django insisted on creating locally. Otherwise we have broken
migrations for the rest of the team.
The choices attribute can point to user overridable settings which can
differ in any and all environments, there is no single representation of
the model in this case. Every django-cms installation has its own list of
available templates in settings.CMS_TEMPLATES which the Page model points
to, so the 'full representation' of the Page model are legion. We'll
eventually wind up with these no-op migrations clashing with real
migrations when a django-cms update includes a new migration:
{{{
CommandError: Conflicting migrations detected (0003_auto_20140926_2347,
0003_auto_20141002_0045 in cms).
To fix them run 'python manage.py makemigrations --merge'
}}}
This comment https://code.djangoproject.com/ticket/21498#comment:9
suggests that the auto detector *has* to pick up any and all changes as it
doesn't know a priori whether it requires DDL work at a later stage. Is
there some point 'later' where the migrations framework can realize it's a
no-op and cancel creating a migrations file (unless of course the user
specified --empty intentionally) or at least provide a way for these to be
ignored?
--
Ticket URL: <https://code.djangoproject.com/ticket/23581#comment:4>
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/068.b688c68a47ccab95a7caa19e7eb70070%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
