How does EF 4 code first handle schema changes in a production environment?

Traditionally I have always written my sql scripts by hand so they are nice and clean (I'm not a fan of the generated ones) and release to release, I provide a fresh install script and a migration script from the previous version that creates new tables, alters existing tables etc. This is all pretty standard.

I haven't really had much time to play around 开发者_如何学运维with EF 4 code first but am quite interested to use it if it is actually viable in a production environment.

Say you have a code first approach where a database will automatically be created if one does not exist. What happens if you release a new version of the software which has schema/model changes. Is EF smart enough to update the database schema to match the updated EF model?

Scenario

1. Client installs asp.net MVC website on their server. Upon first run, a fresh database is created
2. Client uses website for a while and the database gets populated with some data
3. Meanwhile a new version of the website is released and the EF model has changed
4. Client downloads new version, deploys website and points to existing database

Is code first only useful for initial deployment, or is it smart enough to update an existing database release to release like this?

As of EF CTP4, your database will be dropped and recreated every time you change your object model (this is not the default convention and you have to explicitly tell EF Code-First to do so by setting a Database Initializer Strategy).

That being said, EF team are actively working on a Database Evolution (aka Migrations) Solution that exactly addresses your scenario: A solution that will evolve the database schema as your object model changes over time which essentially tries to alter the database to be back in sync with your model instead of recreating it.

As per EF team, this feature will be available as part of EF next version that is on track to be released on the 1st quarter of 2011.

The ability to create a database is just one feature of Code First - and it's an optional feature. You don't have to use this feature at all. In fact, Scott Gu has an entire blog post dedicated to using Code First with an existing database.

Until the Database Migrations are released, you have to come up with another strategy and that strategy will simply be managing your ALTER TABLE scripts as you traditionally would have. So when you deploy a new version, you run your ALTER script and deploy the code that contains the changes to the model.

Having said all that, you get more options in Code First than simply dropping and recreating your database every time (that is just one option). You can also set the initializer to only recreated the database if the model changes. You can also set the initializer to never run at all (in the case where you're manually managing changes to the database). This post will give you more information on EF database initializers.

I am working on database context initializer which will notify webmaster if model and db schema are out of sync. 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

Months have passed and now the official answer has been released: IDatabaseInitializer.

Here's more or less what you're looking for:

public class DoNothingWithMyDatabase<TContext> : IDatabaseInitializer<TContext>
    where TContext : DbContext
{
    public void InitializeDatabase(TContext context)
    {
    }
}

Taken from here: http://blog.cincura.net/231783-ultimate-efv4-ctp4-code-first-full-mapping-example-using-firebird/

Now you can transform your schema the way you're used to. Of course, you could also write a more complex DatabaseInitializer that uses C# instead of SQL, and does more complex things like checking to see if an alter is necessary before performing it, transform data as it changes tables, etc.

Another StackOverflow question that deals with some of the details of modifying tables: Entity Framework Code First fluent API setting field properties in a for loop

Using EF 6 , u can re-engineer your database (code-first) make sure all updates are installed , sometimes u may have different schemas in your existing database to use them in your context class

 modelBuilder.Entity<Charge>().ToTable("FullDepot.Charge");

if you don't EF only picks up dbo.yourtable and not tables like FullDepot.secondtable etc