29

I have been programming recently with Entity Framework 4.1 Code First and am loving it for development, but with only an end plan and a rapidly changing feature list, I am constantly modifying the Class/Database to meet the applications needs.

In development, there is no live data and I can easily just delete the entire database so it is recreated with the new schema however, obviously, when live - this is very bad!

The only solutions I can see are to either drop the metadata table and manually keep the database in sync or basically drop and reseed.

I personally prefer the first method as I think it will be a lot easier to add a column/table than to recreate and migrate data, but, unless I have missed something, this is completely moving away from Code First.

So the question really is, is Code First just about the initial development and what is a good strategy for managing EF for a production environment?

Improve this question
1
  • Been meaning to ask this for a few days, wasn't sure if it was best here or on Stack Overflow...
    – wilhil
    Commented May 13, 2011 at 11:12

3 Answers 3

Reset to default
15

My opinion is that code first's automatic database creation is only for development. I answered similar questions on Stack Overflow where I described both how to upgrade the database and why is automatic functionality bad in production:

Upgrading the database is semi-manual task. There should be no automatic untested magic behind - moreover EF 4.1 currently doesn't have any such magic available (there is only some presentation about features ADO.NET team is working on).

You can also check this question to more better understand how are web sites upgraded.

Improve this answer
5
  • Hello again! -you are quick on EF questions! :) ... Don't know where I would be without you!
    – wilhil
    Commented May 13, 2011 at 11:49
  • A few months on and my program is pretty finished... I am marking this as answer, but, I was wondering if anything has changed / are there any resources that can help?
    – wilhil
    Commented Aug 22, 2011 at 21:12
  • 2
    First public preview of "Migrations" was released. blogs.msdn.com/b/adonet/archive/2011/07/27/…
    – Ladislav Mrnka
    Commented Aug 22, 2011 at 21:20
  • Thanks, looking at that now! I loved developing with Code First, but, I am so nervous/worried about changing later!
    – wilhil
    Commented Aug 22, 2011 at 21:23
  • How do you handle case where StoredProcs or Views are created directly in the DB for other purposes e.g. reporting that are not used by the application. We would need to know which SPs are affected by a schema change in code first.
    – softveda
    Commented Jan 12, 2012 at 21:58
5

Maintain upgrade scripts.

In the database itself, maintain a table where a record is held with the version of the schema.

When you application start, it detects the version against the version supposed to be used by the binaries. If it differs, it execute (or ask the user to) the upgrade scripts.

Don't forget to backup the database first.

Improve this answer
4
  • Next step: you are fired ;) Database updates should not ahppen automatically without a backup first - and possibly in downtime, not when ONE USER runs a newer version. Your approach is perfect - to shut down largeer deployments with tons of errors.
    – TomTom
    Commented Feb 4, 2014 at 12:20
  • @TomTom: that depends. We are running flawlessly a DB application for several years which does exactly this: automatic schema changes for a new release, done by the application when it detects a too-old version. Backups are done daily either, and we keep all schema changes backward compatible (only adding fields & tables, never deleting any). I agree that the measures you mentioned are important when the changes are not backwards-compatible, and you cannot guarantee all client applications to be updated simultanously (for example, for big enterprise DBs).
    – Doc Brown
    Commented Sep 5, 2014 at 4:25
  • On top if the changes are non trivial. Try changing a field in a 2tb table (and yes, I do deal with this - and it is not even a data warehoue). You ahve put yourself up into a scenario where you are accumulating technical debt because you can ony ever ADD fields, never clean up.
    – TomTom
    Commented Sep 5, 2014 at 5:14
  • @TomTom: It is possible to clean up, but you tend to defer it to a post-release time of your choosing. So if update A is released which now no longer uses a certain field, you are correct that you don't immediately remove that field from the db in case of rollback. One company I worked at would schedule a delete of that DB column on the next update (B). Another company would keep it for a fixed 3 months, and then delete it during the next released update. It's all a matter of how long you intend to have perfect rollback ability.
    – Flater
    Commented Mar 1, 2021 at 8:55
2

The question is somehow flawed in that it makes connections between the programming model and the runtime environment where there is none.

Code first is primarily a development speed driver and is not really connected to the runtime system.

In production you will properly have a configuration setting that denies the runtime the possibility of deleting/updating the db model.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.