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. On Friday, 19 June 2020 23:15:31 UTC+10, Alexander Lyabah wrote: > > 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. > -- 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/babfcb07-6a7f-4566-9d43-88551b947b0bo%40googlegroups.com.
