Migrations: Make it easier to revert last migration when removing it

[maumar]

When trying to remove already applied migration we get a message to unapply it first because it's already in the database. However unapplying first migration is not very intuitive, one has to type "dnx . ef migration apply 0" (since we don't have named migration for empty database)

I would much rather have some sort of -force option on ef migration remove that would unapply last migration and then remove it.

[rowanmiller]

Yeah I think a general purpose flag (+ a prompt if it is applied and the flag isn't passed) to allow easily reverting the migration during removal would be good.

[guardrex]

Just ran into this as a new user of EF: It was not intuitive to apply the previous migration in order to unapply the current one in order to be able to remove the current migration.

It seems like if the normal EF sequence is to "add" then "apply" a migration, we should have commands for "unapply" and "remove" that work in the exact reverse. If not, then it might be a good idea that where the exception states:

System.InvalidOperationException: The migration '<migration_id>' has already been applied to 
the database. Unapply it and try again. If the migration has been applied to other databases, 
consider reverting its changes using a new migration.

it would be more helpful to add the phrase "by applying the previous migration," which would have made it very clear to me what I needed to do:

System.InvalidOperationException: The migration '<migration_id>' has already been applied to 
the database. Unapply it by applying the previous migration and try again. If the migration has 
been applied to other databases, consider reverting its changes using a new migration.

[guardrex]

... and "unapply" seems kind of hokey. The antonyms for "apply" are: cease, halt, ignore, mismanage, misuse, and neglect. Maybe "ignore" is the closest in meaning to "unapply" in this context. One would "add"-"apply" then "ignore"-"remove".

[bricelam]

Revert is another word we typically use to mean the opposite of apply.

[bricelam]

Splitting it into two commands--Apply-Migration and Revert-Migration--is a good idea. We could also rename the Up and Down methods to fully align.

[guardrex]

Ah, yes, "revert" is much better.

btw-- #2153 updates for EF migrations worked perfectly. Excellent technology! Next, I'm lick'in my chops for Azure Table Storage support when that arrives.

[rowanmiller]

@bricelam love the command/method naming idea... has a nice symmetry to it 😄

[brent-russell]

I just ran into this trying my first "revert" test. @guardrex 's comments are spot on. I eventually figured it out via a "what if I apply the previous migration?" tangent, but an explicit revert command would be welcome.

FWIW, first I tried "remove" and got the "already applied" error message. Then I ran --help on both "remove" and "apply" to see if there were any options/flags that would either force "remove" to also revert, or reverse the direction of the apply command. I had a brief thought that maybe revert wasn't implemented, and then tried applying the previous migration by name to see what it would do. (I'm not the same new user GuardRex encountered.)

A "revert" command would also be beneficial because it would enable reverting the last applied migration without having to specify the previous migration name.

I don't think renaming the Up and Down methods is necessary. Those names are pretty intuitive. It wouldn't bother me if they were though. It's such a small change. Up and Down is the terminology used by FluentMigrator. So I guess it might be considered an "industry standard".

Thanks to everyone on this issue!

[bricelam]

We talked a bit more about this on the team recently, and our current thoughts were to rename Apply-Migration to something like Migrate-Database. That way it's clearer that it can both apply and revert migrations. The help should read something like "Applies and reverts migrations in the database."

We came to the same conclusions on the Up and Down methods. They're pretty canonical across migration technologies, so keeping them is probably best.

We should add a --force switch to ef migration remove and update the error message to mention it.