Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Using Entity Framework Code First Migrations in a DVCS Project

I have always found version control a bit of an issue when it comes to database schemas.

So - I am currently evaluating Entity Framework Code First Migrations and so far I'm really impressed.

My question is, does anyone have any experience of using Migrations in a team using a DVCS?

If developers working on different branches each create their own Migrations, does the 'Update-Database' tool cope well with that when the branches are merged?

I guess what could happen is that a new Migration would appear in the middle of the list. Would this then get picked up, or does it just look for 'newer' migrations than the last one deployed?

I appreciate the team are going to have to be careful not to create conflicting schema changes - this is something we can manage - but it would be useful to know if 'Update-Database' is smart enough to spot the 'missing' migration?

Thanks, - Chris

like image 570
Chris Roberts Avatar asked Apr 24 '12 12:04

Chris Roberts


2 Answers

According to the one blog post I could find on the topic, it seems that parallel development, regardless of the VCS tool, is problematic with the current state of database migrations in EF. There doesn't seem to be a way to handle the scenario due to how it tracks state of the database. Pawel provides an example project on GitHub to display the issue.

You may actually be far better off using an independent tool to handle your database migrations. I have used Migrator.NET with a great deal of success and it does properly handle parallel developers' schema changes. It also uses a relatively low-tech method of tracking the database "version," which surprisingly works very well as long as you and your team decide on the day that nobody will ever touch the database except through a migration class (we called that day v1 of the database).

like image 113
Sumo Avatar answered Oct 24 '22 17:10

Sumo


The solutions in this article might work for you. You take an extra step of creating a blank migration that ignores the changes from the other developer. This updates the snapshot to be in sync with the database.

http://msdn.microsoft.com/en-us/data/dn481501.aspx

like image 41
Dan Avatar answered Oct 24 '22 15:10

Dan