-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrations: Make it easier to revert last migration when removing it #1972
Comments
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. |
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:
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:
|
... 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". |
Revert is another word we typically use to mean the opposite of apply. |
Splitting it into two commands-- |
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. |
@bricelam love the command/method naming idea... has a nice symmetry to it 😄 |
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! |
We talked a bit more about this on the team recently, and our current thoughts were to rename We came to the same conclusions on the We should add a |
Cool, and I hope you'll consider modifying the exception a bit ... something like,
... we LOB devs aren't too smart (as I prove over and over here)! 😄 |
|
@natemcmaster Would you mind filing a new issue? It's on my TODO list to investigate and write some Migrations end-to-end tests, but having an issue to track it would also be good. |
Note, we used |
Resolves #1972 Also updated T4 template for string resources generation. It had some weird issues. Did manual verification with 1 or more migrations.
Resolves #1972 Also updated T4 template for string resources generation. It had some weird issues. Did manual verification with 1 or more migrations.
Resolves #1972 Also updated T4 template for string resources generation. It had some weird issues. Did manual verification with 1 or more migrations using PMC & dotnet ef both.
Resolves #1972 Also updated T4 template for string resources generation. It had some weird issues. Did manual verification with 1 or more migrations using PMC & dotnet ef both.
Resolves #1972 Also updated T4 template for string resources generation. It had some weird issues. Did manual verification with 1 or more migrations using PMC & dotnet ef both.
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.
The text was updated successfully, but these errors were encountered: