"Ignore missing" option for diesel migration revert --all

[Diggsey]

I've finally got around to implementing a "true" rollback as part of our deployment process, and that requires a better solution for reverting migrations.

For this, I designed the following script to run in our CD pipeline:

# Save all the migrations from the new revision that have been added
cp -pv --parents migrations/.gitkeep $(git diff $BASE_SHA1 $SHA1 --name-only --diff-filter=A --no-renames -- migrations) added_migrations

# Save all the migrations from the base revision that have been deleted
git checkout $BASE_SHA1
cp -pv --parents migrations/.gitkeep $(git diff $BASE_SHA1 $SHA1 --name-only --diff-filter=D --no-renames -- migrations) deleted_migrations

# Revert just the deleted migrations
diesel migration revert --all --migration-dir deleted_migrations/migrations

# Run just the added migrations
diesel migration run --migration-dir added_migrations/migrations

This allows you to simply "git revert" unwanted migraitons, and for those migrations to be reverted as a result.

The new diesel migration revert --all option is almost enough to make this work. The problem is that it tries to revert all applied migrations, not just those present in the migrations folder.

I'm proposing a new command line option for diesel migration revert, --skip-missing. When used, diesel migration revert will not stop if it can't find a migration, it will just continue on to the next. (It could still print out eg. number of migrations skipped).

Given that I need this, I'll be implementing some solution regardless, but I wanted to find out:
a) if there's a better alternative
b) if it's worth trying to upstream

[weiznich]

We might accept such a flag as long as the documentation makes it clear that it really depends on how your migrations are written if this works or not. For the general case I would expect that this will fail horribly as migrations may have dependencies on each other.

[Diggsey]

To be clear: it's not specifically about running them out of order. Even with a git revert, you'll still typically be reverting migrations in exactly reverse order. The problem is that git revert --all will fail even if the migrations to be reverted are in the correct order.

I could split it into two options: --skip-missing and --out-of-order, so --skip-missing would still fail if there was a gap in the migrations to run.

The problem is that at the moment you can revert N migrations, but you can't tell diesel which N migrations you are expecting to revert, so it could end up reverting the wrong migrations - in that case erroring if the last N are not the ones expected would be better than silently succeeding.

[weiznich]

The problem is that at the moment you can revert N migrations, but you can't tell diesel which N migrations you are expecting to revert, so it could end up reverting the wrong migrations - in that case erroring if the last N are not the ones expected would be better than silently succeeding.

If that is the underlying problem, whats about adding an option that allows you to specify which migrations should be reverted exactly. That would allow to error out if there is any newer migration which should normally be reverted first. Maybe combined with an --unsafe-force-out-of-order flag that allows to try to revert the migrations independently from that condition.