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?
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.