[Django] #29198: Add a --plan option to the migrate command
Django
--------------------------------------------+------------------------
Reporter: Craig de Stigter | Owner: nobody
Type: Uncategorized | Status: new
Component: Migrations | Version: 2.0
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 |
--------------------------------------------+------------------------
While migrating a prod database today I found myself feeling
uncomfortable.
In a situation like this:
{{{
[X] 0023_add_fairy_dust
[X] 0021_apply_beers_to_database
[ ] 0022_magik_stuff
[ ] 0024_merge
}}}
... what will happen when I run `django-admin migrate app
0023_add_fairy_dust`? Will `0021_apply_beers_to_database` get unapplied?
Will it try to roll forwards to the merge? Will some dependencies from
another app get pulled in? Will any tables get dropped? Something Else?*
We really need a way to quickly sanity-check what's going to happen,
before actually doing it.
A dry-run option was proposed in #23347 but then everyone missed the
forest for the trees, and it was closed because something about RunPython
not being able to be sqlified.
There are various ways to do this:
* I think a simple `--plan` showing which migrations will be applied (same
as the `showmigrations` option, but for a specific plan, especially for
reverse plans) would probably be enough to ease my mind about unapplying
beers.
* A short summary of the operations involved might be nice.
* Full SQL output might be cool. But it might also be too verbose for a
quick sanity check if there are a lot of changes. And as pointed out in
the other ticket, it doesn't work for RunPython (but that's not really a
good reason to not do it)
I haven't spent much time in newer releases (currently upgrading a large
project from 1.8 to 1.11) but AFAICT this still doesn't exist. Correct me
if I'm wrong.
(*Answer: nothing happens - it says `No migrations to apply.`. I don't
think it's possible to unapply those beers, but that's a separate issue.)
--
Ticket URL: <https://code.djangoproject.com/ticket/29198>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Craig de Stigter | Owner: nobody
Component: Migrations | Version: 2.0
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
Changes (by Carlton Gibson):
* type: Uncategorized => New feature
* stage: Unreviewed => Accepted
Comment:
This seems as if it should be viable, at least at the individual migration
level. The `migrate` command calls `MigrationExecutor.migration_plan()`,
making the plan available prior to running any operations. We could
intercept execution there and format the plan for display.
We could expect to list app_name and migration (in order). Users would
need to look at the migrations for the exact operations but, if I'm
reading the intent here correctly, that would probably be enough.
--
Ticket URL: <https://code.djangoproject.com/ticket/29198#comment:1>
Django
Reporter: Craig de Stigter | Owner: nobody
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* version: 2.0 => master
--
Ticket URL: <https://code.djangoproject.com/ticket/29198#comment:2>
Django
Reporter: Craig de Stigter | Owner: nobody
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Sam Handler):
I'm very interested in some version of this functionality as well, though
my case may be different enough to warrant another ticket. I'd like to see
top-level feedback along the lines suggested by Craig in the specific
"and" general migration case (./manage.py migrate and ./manage.py migrate
account 0001_initial). I'd also like to be able to run `sqlmigrate`
against all pending migrations so that I can easily know the queries that
will be run against the DB. I'm not too knowledgeable about Django's
migration internals (yet!) but am glad to take a first stab at this
functionality!
--
Ticket URL: <https://code.djangoproject.com/ticket/29198#comment:3>
Django
Reporter: Craig de Stigter | Owner: Calvin
| DeBoer
Type: New feature | Status: assigned
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Calvin DeBoer):
* owner: nobody => Calvin DeBoer
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/29198#comment:4>
Django
Reporter: Craig de Stigter | Owner: Calvin
| DeBoer
Type: New feature | Status: assigned
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Calvin DeBoer):
* cc: Calvin DeBoer (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/29198#comment:5>
Django
Reporter: Craig de Stigter | Owner: Calvin
| DeBoer
Type: New feature | Status: assigned
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Calvin DeBoer):
Added a WIP Pull Request that outlines the basic functionality. Main todo
is completing the rest of the testing framework / adjusting code based on
comments from django core maintainers.
Running a {{{./manage.py migrate --plan}}} will yield a look at all the
migrations to be run (in order), which all the operations (in order),
which inclusion on what that migration will do (if it is adequately
defined).
{{{
Planned operations:
migrations.0001_initial
Undo Create model Salamander --> No further Detail
Raw Python operation --> Moves salamander to pond
migrations.0002_second
Undo Create model Book --> No further Detail
Raw SQL operation --> SELECT * FROM migrations_book
migrations.0003_third
Undo Create model Author --> No further Detail
Raw SQL operation --> SELECT * FROM migrations_author
}}}
Thoughts ?
--
Ticket URL: <https://code.djangoproject.com/ticket/29198#comment:6>
Django
Reporter: Craig de Stigter | Owner: Calvin
| DeBoer
Type: New feature | Status: assigned
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 1 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Calvin DeBoer):
* needs_docs: 0 => 1
* has_patch: 0 => 1
* needs_tests: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/29198#comment:7>
Django
Reporter: Craig de Stigter | Owner: Calvin
| DeBoer
Type: New feature | Status: assigned
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Calvin DeBoer):
* needs_docs: 1 => 0
* needs_tests: 1 => 0
Comment:
Added documentation and tests
--
Ticket URL: <https://code.djangoproject.com/ticket/29198#comment:8>
Django
Reporter: Craig de Stigter | Owner: Calvin
| DeBoer
Type: New feature | Status: assigned
Component: Migrations | Version: master
Severity: Normal | Resolution:
| checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/29198#comment:9>
Django
Reporter: Craig de Stigter | Owner: Calvin
| DeBoer
Type: New feature | Status: assigned
Component: Migrations | Version: master
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* needs_better_patch: 0 => 1
* stage: Ready for checkin => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/29198#comment:10>
Django
Reporter: Craig de Stigter | Owner: Calvin
| DeBoer
Component: Migrations | Version: master
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham <timograham@…>):
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"058d33f3eddef950e4266ea942d39b1df95ee5de" 058d33f3]:
{{{
#!CommitTicketReference repository=""
revision="058d33f3eddef950e4266ea942d39b1df95ee5de"
Fixed #29198 -- Added migrate --plan option.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/29198#comment:11>
Django
Reporter: Craig de Stigter | Owner: Calvin
| DeBoer
Type: New feature | Status: closed
Component: Migrations | Version: master
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham):
I found a crash if `RunSQL` is passed a list rather than a string.
[https://github.com/django/django/pull/10420 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/29198#comment:12>
Django
Reporter: Craig de Stigter | Owner: Calvin
| DeBoer
Type: New feature | Status: closed
Component: Migrations | Version: master
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"495abe00951ceb9787d7f36590f71aa14c973d3d" 495abe00]:
{{{
#!CommitTicketReference repository=""
revision="495abe00951ceb9787d7f36590f71aa14c973d3d"
Refs #29198 -- Fixed migrate --plan crash if RunSQL uses a list or tuple.
Also fixed test failures if sqlparse isn't installed.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/29198#comment:13>