[Feature Request] Mark rollback as impossible.

[BigBoyBarney]

Hi! Thanks for the shard!

Sometimes I make changes to the logic in a way that's incompatible with rollbacks. I.e: unifying multiple tables or rewriting the insertion logic in a way that renders something redundant.

In these cases, I currently have the migration file like so:

-- drift:migrate
drop table if exists temp_gacha_history;

-- drift:rollback

It would be cool to be able to mark rollback as impossible, so that it throws an error if it is attempted.

[luislavena]

Thank you for your request @BigBoyBarney, I've been thinking about this for a bit and made me evaluate my usage of Drift.

I normally test migrations that I write by doing migrate and rollback to confirm they work both ways, but I also use on my tests a in-memory DB and do reset to undo all the migrations and migrate them again.

I think adding irreversible migrations may break that workflow, but of course, in my use case, I normally don't generate these kind of migrations.

For example Go's migrate sasy to keep the rollback of those migrations empty: https://github.com/golang-migrate/migrate/blob/master/MIGRATIONS.md?plain=1#L47-L49

The migration files are permitted to be "empty", in the event that a migration
is a no-op or is irreversible. It is recommended to still include both migration
files by making the whole migration file consist of a comment.

I know Rails has the option to raise exceptions on irreversible migrations, but most of the advice there is: don't introduce that kind of migrations and, if you do, then create a new migration that adds the table/fields back.

Do you have any other example on how this is done in other solutions? That could help me evaluate the posibilities.

Thank you.

[BigBoyBarney]

Thank you for taking this into consideration!

I unfortunately have no prior experience with other migration libraries. However, I think that differentiating between a no-op and an impossible rollback is important.

If I merge 2 tables due to redundancy reasons and lack of DB foresight, separating them again is not possible. In these cases, doing a no-op roll back is guaranteed to result in a database error eventually, leading to potential data loss in the process.

Raising a runtime error when attempting to do a rollback marked as impossible would help catch the issue before any data is actually modified.

Maybe something along the lines of

-- drift:migrate
drop table if exists temp_gacha_history;

-- drift:rollback
#impossible

Which would raise at runtime if rollback is called on this migration.

---

Thank you again for Drift, it's a really nice tool and very effortless to use! Fantastic work