Geek Answers Handbook

How to code the code / database schema with code EF 4 first - data migration

What are the best database refactoring methods with codefirst EF4?

I am interested to know how people change classes and database when the RecreateDatabaseIfModelChanges parameter is not possible. Data migration must happen.

Microsoft currently has a solution for this with the first model:

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?

+7
c # entity-framework
source share
3 answers

The EF team is working on a migration 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 a recent European tour that they will release this feature soon. I hold my breath.

EXCITING UPDATE:

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

+1
source share

I am working on a database context initializer that will notify the webmaster if the model and db schema are not synchronized and show what is different. This can be useful for developers who prefer to have full control over both the code model and the database schema. Check this:

https://github.com/rialib/efextensions

+1
source share

In my CodeFirst application, local assemblies have the app.config flag, which means it is not in production. When I'm not in production, it completely destroys and recreates the database. Since my working database user does not have permission to delete the database, even if my web.config conversion is somehow skipped (thus EF is trying to recreate the database) my production database will not be deleted and an exception will be thrown instead .

My workflow is as follows:

  • Check production branch of code with latest changes
  • Fast smoke / regression testing (this should already be done before checking the code in the production branch, but just in case)
  • Download the latest backup of my production database and install it on my local SQLEXPRESS server.
  • Run Open DBDiff between the database created by my local code (although this is production code, since it locally recreates the database) against making the backup.
  • Generated recall scripts and attempted run against production backup
  • Assuming no errors have occurred, rewrite the database that the code generated by the production backup and do a production data test to ensure that all the data has remained intact;
  • Run the scripts in a real production database.

Step # 2 automatically creates a new, clean database based on the latest data model, so I always know that I have an updated database in which there are no artifacts from development efforts that are not yet ready for production.

+1
source share

More articles:


All Articles