6

我有一个我最近使用创建的数据库的本地实例DbContext.Database.Create()，因此该__MigrationHistory表存在一个InitalCreate与当前代码匹配的条目。

但是，Migrations 文件夹中存在一些基于代码的迁移。这些将在我们的开发和登台环境中运行，以使这些数据库与代码保持一致。但是，我不需要在本地应用它们，因为我使用当前代码创建了数据库。

我现在需要对模型进行更改并创建相应的迁移。但是当我运行时Add-Migration TestMigration，出现以下错误

Unable to generate an explicit migration because the following explicit 
migrations are pending: 

[201203271113060_AddTableX, 
 201203290856574_AlterColumnY]

Apply the pending explicit migrations before attempting to generate 
a new explicit migration.

在这种情况下我该怎么办？我不能将 Add-Migration 工具指向另一个环境，因为不能保证版本与我在本地拥有的版本相匹配。我想要一个只匹配我所做更改的迁移。

似乎我有几个选择，但没有一个是理想的：

  1. 从 Migrations 文件夹中删除其他迁移，运行 Add-Migration 命令，升级数据库，然后恢复旧迁移。这很简单，但似乎有点骇人听闻。
  2. 恢复到应用第一次迁移的源代码控制中的模型版本，然后构建它并使用它来创建数据库。然后获取最新版本，应用所有迁移，然后我就可以添加我的迁移了。这似乎是一个很大的努力！
  3. 手动创建迁移。

有人对如何管理这个有任何建议吗？

4

5 回答 5

2

我们计划使用您的选项 #1 的变体...

我们的标准操作程序是为每次迁移生成一个 SQL 脚本（使用 update-database 的 -script 选项），以便通过 InstallShield 将 SQL 脚本应用于最终用户“生产”数据库（我们计划使用 EF update-database 仅适用于开发人员数据库）。

因此，我们在 Migrations 文件夹中同时拥有 Migration .cs 文件和所有迁移的相应 .sql 文件。

因此，我们不是从 Migrations 文件夹中删除迁移（如您在 #1 中建议的那样），而是使用 SQL Mgmt Studio 手动应用 .sql 文件中执行插入到 _MigrationHistory 的部分。

这会使本地数据库的 _MigrationHistory 与已合并到该数据库中的更改保持同步。

但这是一个杂项，我们仍在寻找更好的解决方案。

爸爸猫

于 2012-07-17T18:43:23.467 回答
2

我发现效果最好的方法非常简单：DbContext.Database.Create()启用迁移后不要使用。如果您想以编程方式创建新数据库，请改用迁移 API。

var migrator = new DbMigrator(new Configuration());
migrator.Update();

然后，您将获得完整的迁移历史记录，并按预期添加进一步的迁移。

于 2013-11-05T16:07:22.110 回答
1

您需要update-database从包管理器控制台运行“”以将更改推送到数据库，或者您可以从 Migrations 文件夹中删除待处理的迁移文件（[201203271113060_AddTableX]），然后重新运行“add-migration”以创建品牌基于您的编辑的新迁移。

于 2015-11-23T16:15:36.047 回答
0

我遇到了同样的问题。如果你跑

Update-database

然后运行

Add-Migration YourMigrationName

这解决了问题

于 2013-11-04T03:26:45.007 回答
0

只需从解决方案文件中排除旧的迁移文件。

于 2017-04-05T20:49:02.580 回答