> > manage.py migrate app 0050_migration_from_master will unapply too much > (specifically, all the subsequent migrations from master)
I don't follow you. This is exactly the thing I do, migrating back to the last common migration. On Wed, 16 Dec 2020 at 17:21, Roman Odaisky <rday...@gmail.com> wrote: > Hi All, > > I would like to solicit some further comments regarding #32267. The main > question is: > > Should Django support unapplying migrations in a branch? > > Typical use case: > $ git switch otherdeveloper/feature > $ manage.py migrate > Applying app.0051_migration_from_feature... OK > Applying app.0052_migration_from_feature... OK > Applying app.0053_merge_master... OK > Applying app.0054_migration_from_feature... OK > $ do some work on the feature branch > $ manage.py migrate ??? > $ git switch master > > Despite there being a very clear path from the feature branch to the > master branch, namely, to reverse the migrations that have just been > applied, there’s no way to tell Django to do that. manage.py migrate app > 0051_migration_from_feature will unapply too little (it will keep 0051 > itself applied) and manage.py migrate app 0050_migration_from_master will > unapply too much (specifically, all the subsequent migrations from > master).There’s only this extremely hacky workaround: > > migrate <app> <first migration of feature branch> > migrate --fake <app> <last common migration> > migrate --fake <app> <first migration of feature branch> > migrate <app> <last common migration> > migrate --fake <app> <last master migration> > > Reversing the migrations does not present a potential for DB state > corruption because already existing Django mechanisms prevent unapplying a > migration if its children are still applied. Indeed, Django will happily > reverse the feature branch migration chain... all except the oldest > migration. > > What are the possible pitfalls with allowing Django to reverse a migration > chain, starting with most recent applied migration and ending with a > certain ancestor of that migration? > > The ticket suggests a problem in case someone reverses a migration chain, > deletes migration files and proceeds with committing new work to that > branch. This is indeed an error-prone approach that should not be > supported, for the primary reason that someone who had checked out that > branch earlier and applied its migrations would be stuck. However, what’s > wrong with the possibility of simply switching from that branch without > ever deleting migration files? > > What concerns are there pertaining to a possibility of migrating back to a > node that has multiple children (currently unsupported) that do not apply > to the possibility of migrating back to a node that has only one child > (currently supported)? > > Ticket: https://code.djangoproject.com/ticket/32267 > PR: https://github.com/django/django/pull/13781 > > -- > WBR > Roman. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/85a20b24-3f91-412d-9bce-664ba835d576n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/85a20b24-3f91-412d-9bce-664ba835d576n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Adam -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM0Ru3JHrbeDJPN5tNxeSAqhNCL3ODH4RH27DxOyi_eR6A%40mail.gmail.com.
