I’ve been writing some migrations lately which fall under the Irreversible Migration umbrella. But they aren’t end of the world irreversible. You could roll them back if you want. The scenario I have at the moment is changing a one to many relationship to a many to many relationship. It involves dropping a column and making a new join table. (as well as two lines in the models).
I was thinking, instead of aborting the down migration, I could say something like “This migration is [INSERT SCARY MESSAGE HERE], are you sure you want to proceed? Y/N” and then roll back the migration if they choose to? Just put the migration inside an if statement?
It’s easy enough to make migrations irreversible, and usually there’s good reason (e.g. data can’t be recovered). Do these issues usually get resolved by just writing a migration which does it manually?
In my noobish mind it’d be nice to have a happy medium. Is it wise? Maybe I just don’t understand when to make them non-reversible in the first place.
I always try to make the migration reversible if possible. The only time I think I’ve run into problems is when you go from a coarsely defined data model to a finer grained on, and then back again. I don’t see any reason to not use your solution though, depending of course, on the consequences of the migration. There is also nothing stopping the person running the down migration from commenting out your raised error and writing their own code to reverse the migration, but it is far safer for you, the person writing the data model change to know how to transform back to the previous state instead of them guessing.