Idea for Rollback Migration Rules

110 views
Skip to first unread message

Alexander Lyabah

unread,
Jun 19, 2020, 9:15:31 AM6/19/20
to Django developers (Contributions to Django itself)
I just have a very small idea, maybe I can get a feedback about it here.

What if db will store not only migration name but also migration itself, so the system can rollback the migration even if migration file is no-longer exists.


Cases when it can be useful:

when I switch between branched in my git-repo I want to roll-back migrations that were removed and apply new migrations.

When I change migration itself, I want to roll-back its previous version and apply a new changed version.


Let me know what you think about it, I hope it is a right place to share ideas like that.

Josh Smeaton

unread,
Jul 4, 2020, 8:11:22 AM7/4/20
to Django developers (Contributions to Django itself)
I run into the problem you're trying to solve often and it's quite frustrating. I don't think storing the migration text in the database is the right solution - I don't know why, but it just *feels* wrong.

Such a rollback would only support SQL based migrations - any RunPython migration operations would not be safe to run as the code has changed underneath.

Lorenzo Peña

unread,
Jul 4, 2020, 11:36:16 PM7/4/20
to Django developers (Contributions to Django itself)
See if this solves part of the problem https://github.com/lorinkoz/django-unmigrate

Dwight Gunning

unread,
Jul 5, 2020, 1:58:36 AM7/5/20
to Django developers (Contributions to Django itself)
The first case is definitely a source of friction for me too. Django management commands could help but it's still up to the developer to remember to run them. I'd prefer to have the VCS identify and help resolve these situations right when they arise. 

The second case seems to be discouraged by the docs: "you are encouraged to make migrations freely and not worry about how many you have". Following this guideline, it will only be in rare situations that already applied migrations will be modified. Therefore I don't see a need for framework support in resolving this.

Back to the VCS idea.... and as an aside to Django development:

Looking at the git docs, a post-checkout script could compare the two branches and provide a warning about any change to the migrations in the working tree. Looks like others have thought down the same lines:

I think I'll look into adapting the post-checkout hook in this gist, which differences in PHP `composer.lock` files.

Dwight
--
Reply all
Reply to author
Forward
0 new messages