How to use migrations on an existing db in product

问题:

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:

1. A new developer needs the database created from scratch with seed data. (The Seed() method also applies some unique indices.)
2. 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?

回答1:

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.

1. Upgrade the project to use EF 4.3 (or later) with Migrations and create the initial migration to snapshot what production currently looks like.

   Update-Package EntityFramework
   Enable-Migrations
   Add-Migration InitialCreate  
   

2. Replace your database initializers with matching Migrations code.

   For seed data, add it to the Seed() method of the Migrations\Configuration.cs file. Note that unlike the Seed() method in initializers, this method gets run every time Update-Database is called. It may need to update rows (reset the seed data) instead of inserting them. The AddOrUpdate() 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 the CreateTable() calls using the Index() method, or by calling the CreateIndex() method.

   You can use the MigrateDatabaseToLatestVersion initializer now to run Migrations during initialization.

3. Get a script to bootstrap your production environment.

   Update-Database -Script
   

   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] and INSERT INTO [__MigrationHistory] statements.

4. 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 run Update-Database (or use the Migrations initializer) against production to apply additional migrations there.