#32267: Unable to unapply a branch of migrations
-------------------------------+--------------------------------------
Reporter: Roman Odaisky | Owner: nobody
Type: New feature | Status: closed
Component: Migrations | Version: 3.1
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Changes (by Mariusz Felisiak):
* status: new => closed
* resolution: => invalid
Comment:
> We’re currently at the merge migration 0053m. We’d like to mark 0053m as
unapplied, perform the rollback operations of 0052b and 0051b and end up
at 0052a (at which point we can check out master and forget about the
existence of the abandoned branch and its migrations). Currently this is
only possible (other than rolling back and re-applying the master
migrations, which may not even be an option) by doing a number of `--fake`
migrations in a risk-prone manner.
>
> There needs to be an option to run `manage.py migrate --before myapp
0051b` or something like that, a command that would rollback the specified
migration and all others that depend on it but leaving ones from parallel
branches unaffected. In other words, while `manage.py migrate myapp 1234`
ensures that 1234 is applied, the suggested command would ensure that the
specified migration is //not// applied (unapplying other migrations where
necessary, but as few as possible).
If you've already performed migrations from the feature branch you can
restore the previous state by
[https://docs.djangoproject.com/en/3.1/topics/migrations/#reversing-
migrations reversing migrations] to the `0050`, removing migrations from
the feature branch and applying again `0051a` and `0052a`. You can also
add new migrations that will reverse changes from `0051b`, `0052b`.
Working with migrations on feature branches is difficult and each
situation is different, I don't see a way to add an option to the
`migrate` command that can decide for you. Personally I would recommend
using a separate db for each feature that can be abandoned if not needed.
--
Ticket URL: <https://code.djangoproject.com/ticket/32267#comment:1>
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 django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.a232184269fada37f64ef885837561a4%40djangoproject.com.
