Database migrations for Entity Framework 4

Question

I've been playing with Entity Framework 4, using the model driven approach to generate the database script from my entities. This is great but I'm not sure how this works when it comes to versioning the database. I'm guessing if I wanted to use an active record type migration framework I'd have to work the other way around and generate my entities from my database? Is there any way to use the model driven approach and version the database properly?

Answer 1

This will be coming soon as a NuGet package called EntityFramework.Migrations

A demo was performed by Scott Hanselman at TechEd 2011 (available online at http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/DEV349). The relevant section is 45 minutes in.

In short, once the package is installed, you'll enter the following into the Package Manager Console to generate a database change script:

migrate -script

UPDATE (13-Nov-2011)

The alpha 3 build of this package is now available on NuGet. Rather than use the cmdlet migrate -script mentioned above, it uses the cmdlet Add-Migration <migrationname>. A walk-through of its use can be found on the ADO.NET team blog.

UPDATE (14-Feb-2012)

This functionality is now available as part of the main EntityFramework NuGet package, starting with version 4.3. An updated walk-through using EF 4.3 can be found on the ADO.NET team blog.

Answer 2

You can try Wizardby: this is a tool for managing database migrations. It doesn't integrate with EF (since it's nearly impossible to integrate with it in this respect), but does the job.

Answer 3

ScottGu mentions something about this in a blog entry:

We are also going to be supporting a “migrations” feature with EF in the future that will allow you to automate/script database schema migrations programmatically.

[EDIT]

I think he might be referring to the Entity Designer Database Generation Power Pack, as answered by Morteza Manavi in another SO answer.

Answer 4

Well, if you want to work like ActiveRecord, then you need to work like ActiveRecord. :)

However, if you want to use model-first but still use migrations, this will be possible, but will require extra work on your behalf. Model-first will generate a database change script. You will have to extract the relevant parts into migrations, as well as manually writing undo scripts. Although this involves some manual labor, it doesn't strike me as terribly difficult.

Answer 5

I'm working on an alternative to EF.Migrations library - EntityFramework.SchemaCompare. It allows to physically compare a db schema with an entities model representing database context (EF.Migrations doesn't do it). This can be fired either during database initialization or manually on request. Consider the following example

#if DEBUG
Database.SetInitializer(new CheckCompatibilityWithModel<DatabaseContext>());
#endif

It will throw an exception during database initialization describing the differences between db schema and model if incompatibility issues are found. Alternatively you can find those differences at any time in your code this way

using (var ctx = new DatabaseContext())
{
    var issues = ctx.Database.FindCompatibilityIssues();
}

Then having those differences / incompatibility issues on hands you can either update the db schema or the model.

This approach is particularly useful when you need complete control over the database schema and model design and/or working in a team where multiple team members are working on the same db schema and model. It can also be used in addition to EF.Migrations.

Fork me at GitHub: https://github.com/kriasoft/data