{"id":3654002,"date":"2023-05-04T08:00:15","date_gmt":"2023-05-04T12:00:15","guid":{"rendered":"https:\/\/spin.atomicobject.com\/?p=3654002"},"modified":"2023-05-03T11:26:57","modified_gmt":"2023-05-03T15:26:57","slug":"ef-code-first-migrations","status":"publish","type":"post","link":"https:\/\/spin.atomicobject.com\/ef-code-first-migrations\/","title":{"rendered":"Detecting Errors in Entity Framework Code First Migrations"},"content":{"rendered":"

Our team uses Entity Framework’s code first migrations to manage updates to our database schema. Having not worked much with EF before<\/a>, we didn’t understand the mechanics of managing these migrations well. That, along with a lack of care in reviewing and validating new migrations, led to an embarrassing number of broken migrations reaching our main development branch.<\/p>\n

I’ve learned more about EF code first migrations, since then. However, we still make mistakes that are difficult to catch with code review alone. In this post, I’ll explain the different error cases we’ve encountered. I’ll also talk about how we’ve shifted some of the responsibility for detecting these onto our test pipelines. That increases our confidence in the migrations we let reach our main branch.<\/p>\n

Generating and Applying Migrations<\/h2>\n

I have since read through more EF guides and experimented more with the tool. Here is my current understanding of generating and applying migrations:<\/p>\n

    \n
  1. Before creating a new migration, changes are made to the models and model configuration classes.<\/li>\n
  2. Running dotnet ef migration add MyNewMigration<\/code> adds a new Migration class and updates the DbContextModelSnapshot<\/code> with the new changes to the model\/model configuration.\n