#29198 closed New feature (fixed)
Add a --plan option to the migrate command
Reported by: | Craig de Stigter | Owned by: | Calvin DeBoer |
---|---|---|---|
Component: | Migrations | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Calvin DeBoer | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
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 theshowmigrations
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.)
Change History (13)
comment:1 by , 7 years ago
Triage Stage: | Unreviewed → Accepted |
---|---|
Type: | Uncategorized → New feature |
comment:2 by , 7 years ago
Version: | 2.0 → master |
---|
comment:3 by , 7 years ago
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!
comment:4 by , 6 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:6 by , 6 years ago
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 Create model Salamander --> No further Detail Raw Python operation --> Grows salamander's tail migrations.0002_second Create model Book --> No further Detail Raw SQL operation --> SELECT * FROM migrations_book migrations.0003_third Create model Author --> No further Detail Raw SQL operation --> SELECT * FROM migrations_author
Thoughts ?
comment:7 by , 6 years ago
Has patch: | set |
---|---|
Needs documentation: | set |
Needs tests: | set |
comment:8 by , 6 years ago
Needs documentation: | unset |
---|---|
Needs tests: | unset |
Added documentation and tests
comment:9 by , 6 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
comment:10 by , 6 years ago
Patch needs improvement: | set |
---|---|
Triage Stage: | Ready for checkin → Accepted |
This seems as if it should be viable, at least at the individual migration level. The
migrate
command callsMigrationExecutor.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.