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

Question

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

Client installs asp.net MVC website on their server. Upon first run, a fresh database is created
Client uses website for a while and the database gets populated with some data
Meanwhile a new version of the website is released and the EF model has changed
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?

score 6 · Accepted Answer · edited Mar 17 '22 at 09:03

6

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.

edited Mar 17 '22 at 09:03

Glorfindel

21,988
13
81
109

answered Nov 18 '10 at 03:28

Morteza Manavi

33,026
6
100
83

good to know, although until that feature is in the wild I don't think this is a route I can advocate at the office. – Ken Henderson Nov 18 '10 at 03:58
Yeah I wasn't sure if the EF 4 framework was quite mature enough to handle this. Thanks for the link. I'll hold off on this feature I think and monitor the EF team in early 2011 for updates. Cheers! – Joshua Hayes Nov 18 '10 at 04:16
1

@confusedGeek: Even after release of this feature, I'm confident that no enterprise would give their production database to EF to fix it for them on the fly. The alter script always has to go through the DBAs, be it being written by you or by the EF. – Morteza Manavi Nov 18 '10 at 04:42
I have just watched the mockup video on the linked msdn ef blog. Looks quite interesting. – Joshua Hayes Nov 18 '10 at 04:45
@Joshua: No problem. BTW, if your measure for the maturity of an ORM is its ability to synchronize the DB with your object model, then I would argue that no ORM is mature enough at all. Please note that the core functionality is there and you can use it but you just need to alter your database manually instead of giving it to EF. The EF migration solution is really more a bonus feature than a core functionality. – Morteza Manavi Nov 18 '10 at 04:47

score 2 · Answer 2 · edited Mar 17 '22 at 09:04

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.

score 0 · Answer 3 · edited Jul 16 '15 at 07:10

0

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

edited Jul 16 '15 at 07:10

Kampai

22,848
21
95
95

answered Jul 16 '15 at 06:53

wesley7

101
3

score 0 · Answer 4 · answered Mar 03 '11 at 01:10

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

score 0 · Answer 5 · edited May 23 '17 at 12:06

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

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

5 Answers5