It’s been a few years since I worked with Entity Framework and there have been substantial improvements. Still I have been missing a life cycle view on the database, where the evolution of a database schema during development and maintenance is fully supported. The latest Entity Framework 4.3 release contains EF Migrations which claims to solve the problem. In a series of post I will explore EF Migrations and see if it can do what I want. In this post I will focus on getting Entity Framework to create a database with a decent schema for me. If I succeed I will continue with the migrations tools to see if they are powerful enough for what I want. For the database I want to have a schema that contains the following features:
Database generated int identity(1,1) primary keys.
Most business applications use a database. Creating the database in the first place is the easy part. Continously evolving the database schema during development when multiple team members are doing changes in various parts of the database is one of the hard parts. The really hard part is to be able to upgrade – or revert back to – a specific version of the schema when needed.
In the first post in this series I created a basic database with the EF Code First features. One of the things I couldn’t do there was creating an index, so in this post I will look into adding an index to my database through EF Migrations in Entity Framework 4.3.
This post describes how to add an index separately. If the index is created together with there is a better way, as described in Indexes in Code-Based EF Migrations.
In my series exploring EF Migrations it is time to look into updates to tables. In this post I’ll make a simple update of a table by adding a column to it. Expanding on the example from the previous posts in this series a TopSpeed column is added to the cars table. Before doing the actual update there’s another thing I want to change. When working in a team I don’t think that automatic migrations give control enough. Using them would cause the developers to end up with different migration order for their databases, yet another migration order for the user test environment and finally another migration order in the production environment. I think that it is better to be strict and use manual migrations. So first I’ll disable the automatic migrations that I enabled previously and then go on and add the new column.
In the Adding Indexes with EF Migrations post I showed how to add indexes to a database created by EF Code First with a separate migration step. When using code-based migrations to add a table, there is another, better way to add indexes, if it is done together with the table. If you’ve read my Type Safe SelectList Factory post you know my feelings about code that contains class or property names as strings. I was considering writing a similar post about indexes in EF Migrations until I found out that there is a built in index creation, using lambdas.
To put a bit more stress on EF Migrations I’ll simulate a scenario that should be quite common in a multi developer environment.
Developer A and B gets the latest code from the repository.
Developer A adds a column and checks in a migration.
Developer B adds another column and makes everything ready for checkin. During checkin Deveveloper B finds out about Developer A’s checkin, gets the latest version and then checks in.
When working in a team this is a common scenario. Especially in green field development where the database continously is expanded as more and more features are added.
