Entity Framework 4.3: Code First Migrations and Obsolete EdmMetaData, IncludeMetaDataConvention Classes

You could have noticed that EdmMetaData and IncludeMetaDataConvention classes are obsolete in Entity Framework 4.3 because EF4.3 handles database creation differently supporting database migration. Before getting into details of how EF4.3 works, let us look at how EF 4.1 works.

EF4.1 way...

When EF4.1 creates the database, it stores the hash of the model used to create in the EdmMetaData table. This table contains just one row of the model hash and EF4.1 uses this hash to determine if the model used at the time of creation is the same one being used to access the database now. If the model hash differs, you will get this famous error…

The model backing the 'YourContext' context has changed since the database was created. Either manually delete/update the database…

Can EF4.1 figure out the differences between the model at the time of creation and the model being used to access now through the EdmMetaData table? No, it can’t. Entity Framework didn’t support database migration until EF4.3. Using this model hash, all that EF4.1 can find out is whether the database and model are compatible with each other.

While the model hash is a nicer way to determine the database compatibility, at times upgrading the database when model changes could be an issue as the EdmMetaData has to be generated through EF only. Most likely this could be an issue in enterprise scenarios where another person/DBA upgrades the database. You can prevent EF4.1 from checking the model hash using the following and manually create upgrade scripts.

modelBuilder.Conventions.Remove<IncludeMetadataConvention>();

EF4.3 way…

One of the key features in EF4.3 is Code First Migrations. EF4.3 supports database migration detecting the model changes, and how does this work? EF4.3 uses Code First Migrations to create the database unlike previous versions calling ObjectContext.CreateDatabase. The Code First Migrations essentially creates the database and stores the compressed version of model used for database creation in _MigrationHistory table. The _MigrationHistory table is stored as a system table if possible and you need to look at the system tables to figure out what’s stored.

When the database is created for the first time from the model, the Code First Migrations essentially does a migration for you storing the model in _MigrationHistory. The model details available in this table can be used to upgrade the database in future. So EF4.3 no longer relies on the EdmMeteaData and that tells the story why EdmMetaData and IncludeMetaDataConvention classes are obsolete in EF4.3.

What happens if the database was created using EF4.1 ?

Well, if the database was created using EF4.1, the database will have the model hash stored in EdmMetaData table. EF4.3 still knows to use the EdmMetaData table to check for model-database compatibility if _MigrationsHistory is not available. When the database is found to be incompatible the behaviour will be similar to the previous versions, you will either get the infamous exception or the database will be dropped and recreated depending on which initializer is configured with.

In summary, EF4.3 supports database migration by storing the compressed model in _MigrationHistory table but yet knows how to use EdmMetaData model hash generated by previous versions.