Migration "rebase", or just an "undo" that works with conflicts

[Shai Berger]

Hello,

Part of my work lately was to help bring a large, complex project from Django
1.7 to 1.8. This effort was being done in parallel to continued development of
the project, in a separate branch. To make things more fun, the project uses
UUID fields for PKs in many models; on 1.7, this was done with django-uuidfield,
but of course, with 1.8 we changed this to models.UUIDField. As a result, many
apps have migrations for moving to 1.8 (there are also a few more for
EmailField's etc).

I found myself, several times, getting new migrations in an app where I've
already added the 1.8-related migrations. When this happened, what I'd like to
do is "rebase" the migration -- undo it, delete it, and recreate it on top of
the newly-added migrations.

However, doing that turned out hard. Not only is there no single operation for
it, I couldn't even do the parts easily -- I could neither undo the migration
nor even fake it out, because the migration folder was in a "merge conflict"
state (more than one final migration).

A rebasemigration command would be wonderful. But the building block for it --
the ability to undo a single migration, even when a conflicting one has been
added to the tree, seems both more essential and easier to do.

Thoughts?

Thanks,
Shai.

[Silvio]

I've had this situation come up too. It would indeed be very useful.

Django South had something vaguely related:

http://south.readthedocs.org/en/latest/tutorial/part3.html

However, the command did not make it over to built-in migrations.

[Andrew Godwin]

You can undo a migration manually using migrate, though if you're in multiple-tip-migration scenario you may need to make a merge migration first (but not apply it) or switch to a branch with only the migration you wish to undo.

The more general rebase command would be interesting, though I've always been wary about adding one, as it's not a guarantee we can always keep - some operations are irreversible, and in Django's case, a migration may not be undoable without other related migrations for foreignkeys, so deleting a migration would likely require deletion of those target migrations as well, potentially?

Andrew

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/77b63ad8-a16b-4ba3-bf3a-3ae5885f85e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Shai Berger]

On Tuesday 01 December 2015 08:40:34 Andrew Godwin wrote:
> You can undo a migration manually using migrate, though if you're in
> multiple-tip-migration scenario you may need to make a merge migration
> first (but not apply it) or switch to a branch with only the migration you
> wish to undo.
>

Yep. But this is highly unintuitive: "To fix it, first make things worse".

> The more general rebase command would be interesting, though I've always
> been wary about adding one, as it's not a guarantee we can always keep -
> some operations are irreversible, and in Django's case, a migration may not
> be undoable without other related migrations for foreignkeys, so deleting a
> migration would likely require deletion of those target migrations as well,
> potentially?
>

Oh, I'd definitely not want that. If, in order to rebase a migration, I'd find
that I need to roll other migrations back, I'd expect the rebase to fail.

Similarly, if I get my "conflict-resistant undo", I'd expect it to require that
the migration can be rolled back on its own. If others are dependent on it,
they should be rolled back explicitly -- I'd really like to minimize automatic
decision-making in a less-than-stable state.

Shai.

[Andrew Godwin]

As long as whatever tool we have fails hard rather than doing weird things with related dependencies, I'm in favour of automating the process more - we should reduce friction around migrations wherever possible.

As for undoing a conflicted migration, it should be relatively simple to make the twin-tip check on the migrate command if you're asking to reverse one of those tips; that should solve that issue.

Andrew