Could this work with Code-First?

Dec 1, 2010 at 7:56 PM

EF CTP4 (Code-First) tighly binds itself to the schema definition of the database based on a hash value created and optionally stored within the database.  It uses this instead of a literal EDMX file.

If the object model differs from the database schema, EF will raise an exception when the context is first created (and possible while running, although this has not been tested).

In live Azure and SQL Azure production environments utilizing EF (specifically Code-First once it reaches RTM leveraging DbContext etc), this presents a serious issue.

When performing rolling upgrades from Staging to Production, there will be instances where the code running on an existing production server will be out of sync with the schema changes performed on the SQL Azure system during migration. 

One logical upgrade path is to test in a separate staging environment, but if the staging requires a schema change to operate the new code base, then the production SQL Azure database will change on the fly, rendering the code in the existing production web roles to fail (because EF Code-First will notice the schema to be out of sync, or worse).

Can your technology be used to essentially "handle" this interim scenario, where the database schema may change underneath the previously assumed model while using EF Code-First?

This of course has some limitations, such as the new schema may not be able to "remove" data from the previously assumed schema and object model - but in the case where a schema change essentially supplements / adds columns or new tables to the model, can the older EF with Code-First engine be fooled into operating during the period where the database schema change has occurred, but the code change to the production web role has not yet taken effect?

I'm uncertain of a clean approach to solving this issue if EF is to be leveraged on SQL Azure.

An alternative is to not rely on EF while in the cloud, thus handling these mappings manually and gaining far more flexibility during migrations; but the whole point of EF is to make database development easier.

Any thoughts or ideas?