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?

wilhil
  • 1,002

3 Answers3

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.

Glorfindel
  • 3,167
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.

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.

casper
  • 99