I have a system in production which was created with Entity Framework 4.1 Code First. Now, I have upgraded to 4.3 and need to apply migrations, but there's several use cases I need to cover:
- A new developer needs the database created from scratch with seed data. (The
Seed()
method also applies some unique indices.) - The production environment needs only the unapplied changes applied. (But keep in mind that this DB was created in EF 4.1, which doesn't have migrations.)
How do I create the migrations and an initializer (or initializers) to cover both these cases?
Since your production database was created with EF 4.1, you'll need to do a bit of work to get it ready for use with Migrations. Start with a copy of your current production code running in a dev environemnt. Make sure the dev database doesn't exist.
Upgrade the project to use EF 4.3 (or later) with Migrations and create the initial migration to snapshot what production currently looks like.
Replace your database initializers with matching Migrations code.
For seed data, add it to the
Seed()
method of theMigrations\Configuration.cs
file. Note that unlike theSeed()
method in initializers, this method gets run every timeUpdate-Database
is called. It may need to update rows (reset the seed data) instead of inserting them. TheAddOrUpdate()
method can aid with this.Since your unique indecies can now be created with Migrations, you should add them to the
Up()
method of the InitialCreate migration. You can either chain them off theCreateTable()
calls using theIndex()
method, or by calling theCreateIndex()
method.You can use the MigrateDatabaseToLatestVersion initializer now to run Migrations during initialization.
Get a script to bootstrap your production environment.
From the script that gets generated, you'll want to delete almost everything since the tables aready exist. The parts you'll need are the
CREATE TABLE [__MigrationHistory]
andINSERT INTO [__MigrationHistory]
statements.Optionally, drop the
EdmMetadata
table since it is no longer needed.Once you do these things, you should be good to go with Migrations. New developers can run
Update-Database
to create the database from scratch, and you can runUpdate-Database
(or use the Migrations initializer) against production to apply additional migrations there.