How Refactor Code/DB schema with EF 4 code first - Data Migration

Question

What are the best practices for database refactoring with codefirst EF4?

I am interested to hear how people change the classes and the database when the RecreateDatabaseIfModelChanges option is not feasible. Migration of data will need to occur.

Currently Microsoft has a solution for doing this with model first:

http://blogs.msdn.com/b/adonet/archive/2010/02/08/entity-designer-database-generation-power-pack.aspx?PageIndex=2#comments

Does anyone have a good strategy for code first?

Obligate

What exactly are you looking for? You don't have to refactor your DB schema with CF. – Gerund

you don't have to refactor it if you blow it away and recreate, but otherwise, you will need to write and apply migration scripts to it will you not? Otherwise it won't match the code. – Obligate

Answer 1

The EF team have been working on a migrations feature for EF that should solve this problem.

http://blogs.msdn.com/b/efdesign/archive/2010/10/22/code-first-database-evolution-aka-migrations.aspx

Scott Gu said on his recent tour around Europe that they should be releasing this feature soon. I'm holding my breath.

EXCITING UPDATE:

This has now been released as a CTP: http://blogs.msdn.com/b/adonet/archive/2011/07/27/code-first-migrations-august-2011-ctp-released.aspx

Tit

Answer 2

I am working on database context initializer which will notify webmaster if model and db schema are out of sync and will show what differs. This can by useful for developers who prefer to have complete control both over code-first model and database schema. Check it out:

https://github.com/rialib/efextensions

Gilead

Answer 3

In my CodeFirst application, local builds have a app.config flag that denotes not being in production. When I'm not in production it completely nukes and recreates the database. Since my production database user does NOT have permissions to drop the database even if my web.config transform is missed somehow (thus EF tries to recreate the database) my production database will not be deleted, and instead an exception will be thrown.

My workflow goes like this:

1. Check out production branch of code with latest changes
2. Quickly smoke/regression test (this should already be done prior to checking code into the production branch, but just in case)
3. Download the latest backup of my production database and install it on my local SQLEXPRESS server
4. Run Open DBDiff between the database my local code created (even though it's production code, since it's local it recreates the database) against the production backup.
5. Review scripts generated and attempt to run them against the production backup
6. Assuming no errors occurred, overwrite the database that the code generated with the production backup and do testing against the production data to make sure all data is intact still;
7. Run scripts on the real production database.

Step #2 automatically creates a new, clean database based on the latest data model so I always know I have an up to date database that doesn't have artifacts from development efforts that may not be production ready yet.

Contradistinction