[Django] #25413: Add an option to squashmigrations to remove RunPython and RunSQL
Django
---------------------------------------+------------------------
Reporter: mjtamlyn | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
---------------------------------------+------------------------
Migrations (correctly) do not optimise through RunPython and RunSQL
commands. However many of these commands are data mutating, rather than
creating initial data, and once they have been applied to all deploys (so
the original migrations files can be removed) they are no longer relevant.
It would be nice to have `./manage.py squashmigrations --no-data` or
similar which simply removes these operations and optimises without them.
--
Ticket URL: <https://code.djangoproject.com/ticket/25413>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: mjtamlyn | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: master
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 timgraham):
* stage: Unreviewed => Accepted
Comment:
I had this use case when squashing migrations for some djangoproject.com
work. What I did was generate a new "initial" migration (which contained
only `CreateModel` operations instead of many `AlterField` operations that
weren't optimized despite the fact that `RunPython` weren't between them)
for the app and then copied the "replaces" attribute from the migration
that `squashmigrations` generated to generate my own squashed migration. I
wonder if this is a workflow we should recommend (automating it could be
nice, I guess).
--
Ticket URL: <https://code.djangoproject.com/ticket/25413#comment:1>
Django
Reporter: mjtamlyn | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: master
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by mjtamlyn):
I think the default behaviour (not doing this) is correct, but I think it
should be easy to do
--
Ticket URL: <https://code.djangoproject.com/ticket/25413#comment:2>
Django
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
Reporter: mjtamlyn | Owner: nobody
Type: New feature | Status: closed
Component: Migrations | Version: master
Severity: Normal | Resolution: duplicate
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by mjtamlyn):
Agreed the proposal in #24109 is better, I didn't find that when searching
because I had no idea what elidable meant.
--
Ticket URL: <https://code.djangoproject.com/ticket/25413#comment:4>