【问题标题】:EF backward compatible DB migrationsEF 向后兼容的数据库迁移
【发布时间】:2014-11-13 17:06:04
【问题描述】:

我试图弄清楚如何使用 EF 代码优先和迁移来实现以下部署方案。 这个想法是我想用向后兼容的模式更改升级数据库(例如:添加一列)并测试一切是否仍然有效。它受到绿/蓝部署的启发,但并不完全遵循这种模式。这背后的原因是遵循这个过程:

  1. 升级数据库(EF 迁移)
  2. 测试网站
  3. 更新网站代码
  4. 如果出现问题,请恢复到以前的网站代码

我肯定会面临的问题是,在第 2 步(和第 4 步)中,我肯定会从 EF 收到关于模型正在更改的错误,尽管所有数据库更改都与现有代码兼容...

我知道一个解决方案是将“Down”数据库迁移到以前的版本(甚至进行数据库备份),但可能会发生某些迁移非常复杂并且“Down”部分可能会损坏或只是编码不好。

所以我的问题是:有没有办法避免 EF 检查模型或最终意识到更改是向后兼容的?

【问题讨论】:

    标签: c# asp.net-mvc entity-framework entity-framework-migrations


    【解决方案1】:

    将 dbinitializer 设置为 null 将放弃兼容性检查,例如

    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; }
    }
    

    还建议here

    【讨论】:

    • 有趣...我被部署位所困扰,找不到那个问题。无论如何,没有办法检查前向/后向兼容性,对吧?我想你可以有完整的检查或根本没有......
    • 我不知道。我不会关闭兼容性检查,因为这会让您更加头疼......如果可能的话,我建议在本地/或通过构建服务器进行回归/集成/单元测试。如果您依赖某些数据,您可以在测试中使用脚本或创建自定义 db-initializer 并覆盖其种子方法。
    • 在几种情况下很有用 - 在我的情况下,我有一个带有 EF 上下文的 nuget 包,在我用最新版本更新它们之前,我不能让每个使用它的站点都关闭.它还允许语义版本控制,其中可以更改次要版本(例如,通过在修复错误时添加额外的列)并且同一主要版本上的任何人都保持兼容。
    猜你喜欢
    • 2016-10-11
    • 1970-01-01
    • 2018-06-02
    • 1970-01-01
    • 2014-02-19
    • 2018-06-19
    • 2019-08-03
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多