#25413: Add an option to squashmigrations to remove RunPython and RunSQL
-----------------------------+-------------------------------------
Reporter: mjtamlyn | Owner: nobody
Type: New feature | Status: closed
Component: Migrations | Version: master
Severity: Normal | Resolution: duplicate
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+-------------------------------------
Changes (by carljm):
* status: new => closed
* resolution: => duplicate
Comment:
I think this is a duplicate of #24109. They aim to solve exactly the same
problem, though they propose different UI for it. #24109 proposes that a
specific operation instance can be explicitly marked as elidable (in which
case squashmigrations would always feel free to collapse it), whereas this
ticket proposes providing an option to the `squashmigrations` command to
automatically elide all `RunPython` and `RunSQL` migrations.
I think the proposal in #24109 is better, because whether a
`RunSQL/RunPython` operation is elidable when squashing is really a
property of the specific operation instance, not a general property of the
entire migration set. For instance, in the same migration set I might have
a `RunSQL` operation which is a pure data migration, and totally safe to
elide when squashing, and another `RunSQL` operation which is an actual
schema alteration, and not at all safe to elide. The proposal here would
give me no way to handle that situation correctly.
But regardless of what UX we settle on, I don't think we need two separate
tickets to track the problem and a potential solution.
Tim, I think the problem you outline is a different problem entirely
(though related), and deserves its own ticket. The first question it
raises is "why weren't those `AlterField` operations squashed; maybe
that's a bug in the optimizer?" The second question it raises is a
potential new feature, which is a totally different (and less safe, but
more likely to result in a "clean" squashed migration) approach to
squashing, where instead of taking the existing operation set and running
the optimizer over it, we simply ignore the existing migration set
entirely and generate a brand-new initial migration based on the current
models. I think this is a new feature worth having (though its limitations
would need careful documentation), but I don't think it's quite the same
feature this ticket was requesting.
Closing this as dupe of #24109; feel free to open a new ticket for the
"ignore existing migrations" version of squash.
--
Ticket URL: <https://code.djangoproject.com/ticket/25413#comment:3>
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/066.952fc581673f686664b548b7d0f2d048%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
