当SQL Azure中不存在数据库时,是否需要首先迁移EF代码?

时间:2015-11-18 20:19:51

标签: c# database entity-framework azure ef-migrations

我尝试了很多EF迁移v6.0.1的变体(从没有数据库,到空数据库到现有数据库),我有一个特殊的问题, Azure 数据库实例无法正确使用Octopus deploy在第一次部署时创建。

有很多地方可能会出错,所以我想如果可能的话,我会和你们一起检查EF Code First迁移的一些基础知识:

如果我创建了代码优先模型,并且知道Azure上预期目标数据库服务器中的数据库不存在。使用默认的' CreateDatabaseIfNotExists'禁用AutomaticMigrations处理;

如果我再拨打' migrate.exe'使用包含我的DbContext和迁移配置的程序集,我将获得使用模型的当前状态创建的新数据库吗?或者我会得到一个没有任何内容的新数据库?即我是否需要明确地添加 - 迁移'对于模型的初始状态?

我在文档中已经读过数据库实例应该由迁移过程自动创建,但是没有人明确(至少对我来说)这个新创建的数据库将使用当前模型生成而没有正式的&# 39;初始状态'迁移创建。

所以问题是:我是否需要为migrate.exe生成显式迁移模型?

通过我尝试的任何方式,我获得了一个数据库,但是应用程序启动了不友好的消息"模型兼容性无法检查,因为数据库不包含模型元数据。只能检查使用Code First或Code First Migrations创建的数据库的模型兼容性。"记住这是刚刚创建数据库的同一个应用程序库(从头开始)我不明白这是怎么发生的!

我通过SQL Server管理工作室手动删除了几次目标数据库,这是不是很糟糕?我是否删除了一些需要恢复的重要用户帐户?

2 个答案:

答案 0 :(得分:2)

迁移和数据库初始化程序CreateDatabaseIfNotExists 不一样

迁移使用数据库初始化程序MigrateDatabaseToLatestVersion,它依赖于数据库_MigrationsHistory中的特殊表。

相比之下,CreateDatabaseIfNotExists是依赖于特殊数据库表EdmMetadata的数据库初始化程序之一。它完全符合它的含义:创建一个数据库,其表格与模型的当前状态相匹配,即只有当数据库不存在时,每个DbSet<T> 的表

此处引用的特定错误Model compatibility cannot be checked because the database does not contain model metadata.是由于{/ 1}}对象的存在而发生的,这些对象在初始数据库创建后添加到代码库中,并且DbSet<T>中不存在。

有4种基本的数据库初始化程序可用,其中3种用于不使用迁移时使用:

  • EdmMetadata
  • CreateDatabaseIfNotExists
  • DropCreateDatabaseWhenModelChanges

另请注意,即使 DropCreateDatabaseAlways被禁用,第4个初始化程序MigrateDatabaseToLatestVersion也允许您使用迁移; AutomaticMigrations有不同的用途,不直接与数据库初始化程序交互。

如果您打算使用迁移,则应将Database Initializer更改为AutomaticMigrations并忘记其他3.如果您打算使用迁移,那么选择初始化程序是情境化的。

    当您确定数据模型未进行主动更改时,
  • MigrateDatabaseToLatestVersion将更合适,并且您只打算关注新部署中的数据库创建。此初始化程序将确保您不会意外删除数据库或实时数据。
  • 当您经常更改模型并且希望能够验证模型的这些更改时,
  • CreateDatabaseIfNotExists最适合开发。它不适合生产服务器,因为对模型的更改可能会无意中导致重新创建数据库。
  • DropCreateDatabaseWhenModelChanges仅适用于测试,每次运行测试时都会从头开始创建数据库。

迁移不同于这3个数据库初始化程序,因为它从不删除 数据库 ,而是使用Data Motion执行一系列DropCreateDatabaseAlwaysCreate Table SQL调用。

您也可以随时在Package Manager控制台中使用Drop Table,无论您使用哪个Database Initializer,都可以生成一个完整的SQL脚本,可以针对服务器运行以重新创建数据库。

答案 1 :(得分:0)

首先,非常感谢Claies帮我解决了这个问题。我已经接受了他的答案是正确的,因为最终它是他的反应和一些额外的阅读能力让我得到了解决方案的结合。

回答实际的帖子问题&#39;当SQL Azure中不存在数据库时,我是否需要首先迁移EF代码?&#39;如果您禁用了自动迁移,则答案是肯定的。但还有一点需要注意:

这个特殊问题的Azure方面实际上与我的情况无关。我的问题是双重的:

  1. 生成的迁移与目标模型不同步。我的意思是什么?我的意思是,我从我的本地数据库生成迁移脚本,该脚本本身与创建迁移不正确的本地代码库不同步。这可以通过比较__MigrationHistory中模型文本的前几行来看出。通过引用这个有用的post来解释这种意识,它解释了它的工作原理。

  2. 更令人尴尬的是(我确定我们都已经完成了)是我的网站本身的章鱼部署(使用Octopack)以某种方式忽略了包含Web.Config文件。据我所知,这可能是在我向Visual Studio安装转换扩展后发生的。在我的nuget包中,我可以看到有一个web.config.transform文件,但没有web.config。基本上这意味着当应用程序启动时,它没有要转向的配置文件,根本没有连接字符串。但这导致了一个轻微的误导性错误

  3.   

    无法检查模型兼容性,因为数据库没有   包含模型元数据。

    虽然它应该说的是,但是你没有连接字符串。 希望这能帮助人们在阅读了Claies的回答和博客文章后更好地理解这个过程。首先,检查你有一个web.config文件,并且它有一个连接字符串......