rollback to a specific migration, or multiple steps

[greglearns]

Is it possible (or, could it be made possible) to 1) rollback more than one step at a time, and 2) (ideally) rollback to a specific named or timestamped migration?

Thank you, and great work!

[amacneil]

Hey, thanks for the suggestion. This is a good idea, I would like to implement it for both migrate and rollback commands. I think we could support both specific versions and numbers:

$ dbmate migrate 20180124013241   # migrate up to and including "20180124013241"
$ dbmate rollback 20180124013241  # rollback any migrations greater than "20180124013241"
$ dbmate rollback n               # rollback last n migrations (where n < 100 for easy parsing)

Do you agree with the logic? Migrating forward n migrations would not work since it's possible for migrations to be applied out of order, so it would not be deterministic and seems easier to leave out.

[matthewlenz]

Right now dbmate appears to apply any missing migrations from the specified path regardless of their naming. For example if I add a new migration file that has an older timestamp than the one that is currently applied to the db it still attempts to apply it. I like this functionality! That begs the question. When you give examples above of "# migrate up to and including "20180124013241" what does that mean? Based on the default table order they are currently applied in the schema_migrations table? sorted alphabetically based on the local disk? EDIT: Added clarification in a new issue.

[amacneil]

migrate up to and including "20180124013241" would mean apply any missing migrations (on disk in the migrations folder) where the version number is alphabetically equal or the same as the target version.

For a rollback, we would similarly only rollback migrations where you have the migration file on disk.

[malinink]

@amacneil is there any plans to deliver that stuff?

[amacneil]

Not currently working on this feature, but PRs to implement it are welcome.

[jayarjo]

Would have been great to have this.

[gregwebs]

There are multiple PRs open that address this issue.

[gregwebs]

PR #438 satisfies this feature request.