Possible pitfall when using EF Migrations

Recently the EF migrations package reached version 0.8 beta. The goal is to include this in the upcoming EF release.  Today EF code first has a simple model of initializers. This solves simple scenarios when developing and changing model or deploying a brand new instance.

Migrations continues the story, to handle just that. Migrations. Change of your model during the lifetime of your application.


Migrations offers automatic migrations or non automatic migrations. In the latter there are two key parts. DbMigrationsConfiguration<TContext> and DbMigration.  Configuration is for settings like automatic migrations and allowing data loss. The former responsibility of the Initializer to seed data also resides in configuration. Now seeding is done when all migrations has run. The DbMigration class describes the model changes to update or downgrade the database.

What I learned

The order of sets in your context matters! The convention for naming relation tables may choose different name depending on the order. This can cause some nasty things in your migrations!

Lets say we have a model where Foo and Bar have a many to many relationship. EF might represent the relationship table as FooBars.

If we later add to our model some other object relation to Foo or Bar and update our Context, EF may then represent the same relation as BarFoos. This has nothing to do with migrations, it has to do with the order of your set in the context. You might not have noticed this when working with Initializers, BUT when reviewing generated DbMigration classes you will. In a migration scenario this could also mean that you lose data due to dropping and recreating relationship tables.



Some friendly advice is to review your migrations or manually configure naming of relationship tables for full control.

Nice to see migrations as another ingredient added to the 4.5 kettle.


Leave a Reply

Close Menu