One of the greatest feature of Entity Framework are Migrations. Today I’ll tell you what Migrations are, how to create and use Migration. Finally I’ll tell you what limitations of Migrations are. I am personally a fan of automation and Migrations are all about automatizing database upgrades and downgrades.
What are Migrations?
As I said before, migration is way EF creates, updates and downgrades database. Every time entity model changes we need to generate migration, which will be used to apply that change to database. In the other word, migration is generated code which links our entity model and SQL scripts send to database, it’ll be clear when we’ll see an example.
How to create Migration?
Having code from last post, we need to do last thing before we can start using API, we need to add Migration. We can create migration by running Add-Migration in PackageManager Console. Add-Migration -Name "BlogPostBasic" will create new migration with name BlogPostBasic. I’ll not copy-paste code here, you can check it here to be perfectly honest there’s a lot of magic, which you don’t need to fully understand, it’s good practice to go thru generated migration when you make big breaking changes in database.
What’s happened?
As you can see EF generated migration class with two methods. Up is used to upgrade database, Down is used to downgrade it. It is one of the best things, normally developer who creates upgrading script doesn’t “waste” time to create downgrading script, because why would anyone want to rollback his changes. EF will create downgrading script for us for free. It is great, because we have opened gate, if something went wrong with our upgrade script, we can always downgrade database. Well, not really always, but this is topic for another post. It is possible to make updates on database where there’s no way back, like changing PK, you’ll need to create script for it manually, and I can tell you now, it’s going to be tough.
More about migration
There is one important thing about generating migration that we need attend to before we can start doing really fun things. There are two ways to run EF commands. You can use Powershell (Package Manager Console) or dotnet cli. I’m using PMC in VisualStudio, because it’s easier. On the other hand, when I was playing with Docker and created image to upgrade database I’ve used dotnet cli. It’s not important, which you’ll pick, but you need to know that syntax for both is different.
I won’t cover differences between Powershell and dotnet cli here. You can read about it here: Package Manager Console, dotnet cli. You don’t need to remember it. It’s enough if you’ll know where to find it (most of programming is about it, just learn basics and know where to find details, it is additional reason I’ve started blogging).
Upgrade database
Now as we have migration created, we only need to use them. I will describe everything on PMC example. Dotnet cli differ only in syntax. `Update-Database` applies migrations to database. We can also select to what point we want to upgrade database by specifying migration name or number. If we would have 3 migrations First,Second and Third we can decide that we want to upgrade database only to First version by calling Update-Database –Migration First. Calling Update-Database without any parameter will upgrade database to last migration.
Downgrade database
When you decide to downgrade database to earlier version it’s as easy as upgrading database. You just need to run Update-Database with parameter name or number of desired migration (version). If you want to remove every migration you can run Update-Database 0. This will restore database to state from before first migration.
Remove Migration
Remove migration is useful when you messed something during creating migration or you remembered that you want to add something else in the same migration. It’s not rocket science, Remove-Migration works the same way as Update-Database works.
There is only one thing. You can’t remove migration if your database is already updated. You need to downgrade database and only then you can remove migration.
Advantages and Limitations
Migration is great tool for versioning database. It’ll make sure that there won’t be case with two developers pushing migration with the same name. It may seem like minor problem, but I worked in project where we didn’t have versioning tool. We had to reserve script file number and still there were cases that two scripts with the same name were created. Additionally EF will make sure that every migration will be applied in correct order. It’s impossible to lost one upgrade with EF. If you were upgrading database manually you should know that it’s super easy to skip one upgrade script and screw your database up.
Additionally, even if you don’t trust EF and you want to create update scripts manually, you can still use Migrations to apply them. Just add your SQL into created migration. It’s wise to use EF even if you want to write SQL scripts. You can find more in this Stack question
I’m using migrations for 2 years now and I can’t see flows in it. It’s partly because I’m using it mostly in my private projects, commercially we’ve been upgrading database from SQL. Migrations provide great versioning tool and easy, user-friendly way to update database. It need some knowledge and everyone need to remember about generating new migration every time they update entities, but apart from that, there’s nothing I can think of. After all migrations are very similar to DacPac.
On the other hand,there are people who don’t like to run automats in their production database. I don’t blame them, production databases are big and losing it is not an option. We’ll talk about migration vs dacpac vs manual scripts in production in the future.
Outro
Next time we’ll inspect controllers in example project. From that point we’ll be done with whole basic project, and we’ll start more advanced one. If you have any question don’t hesitate to ask. See you next time.