6

I'm trying to figure out how to implement the following deployment scenario using EF code-first and migrations. The idea is that I would like to upgrade the DB with backward compatible schema changes (e.g.: add a column) and test that everything still works. It is inspired by green/blue deployment but it's not entirely following that pattern. The reasoning behind this is in following this process:

  1. Upgrade database (EF migration)
  2. Test website
  3. Update website code
  4. If something goes wrong, revert to the previous website code

The problem I will certainly face is that at step 2 (and 4) I will surely get an error from EF about the Model being changed, although all the DB changes are compatible with the existing code...

I know that a solution would be to migrate "Down" the database to the previous version (or even do a DB backup), but it may happen that some migrations are really complex and the "Down" part may be broken or simply poorly coded.

So my question is: is there a way to avoid EF checking the Model or eventually be aware that the changes are backward compatible?

Tallmaris
  • 7,605
  • 3
  • 28
  • 58

1 Answers1

4

Setting the dbinitializer to null will drop the compability check, e.g.

public class MyDBContext: DbContext 
{
    public MyDBContext() : base("myConnString")
    {            
        //Disable initializer
        Database.SetInitializer<MyDBContext>(null);
    }
    public DbSet<A> As { get; set; }
    public DbSet<B> Bs { get; set; }
}

Also suggested here

Community
  • 1
  • 1
Indregaard
  • 1,195
  • 1
  • 18
  • 26
  • Interesting... I was sidetracked by the deployment bit and could not find that question. Anyway, there is no way of checking forward/backward compatibility right? I guess you can either have the full check or not have it at all... – Tallmaris Nov 14 '14 at 09:40
  • Not that I know of. I wouldn't turn off the compability check as this migth cause you even more headaches... If possible i would suggest doing regression/integration/unit tests locally/or by a build server. If you rely on certain data you could either use scritps in tests or create a custom db-initializer and override its seed method. – Indregaard Nov 14 '14 at 13:16
  • Useful in a couple of situations - in my case, I have a nuget package with an EF context and I can't have every single site using it going down until I have updated them with the latest version. It also allows semantic versioning, where minor versions can be changed (e.g. by adding extra columns while you fix bugs) and anybody on the same major version remains compatible. – speciesUnknown Oct 31 '18 at 15:01