[英]Migrations in Entity Framework in a collaborative environment
我们有多个开发人员在开发一个使用 Entity Framework 5.0 的项目。 每个开发人员都使用自己的本地 SQL 2012 数据库，因此他可以在不妨碍其他人的情况下进行开发和测试。
起初，我们混合使用了自动迁移和基于代码的迁移。 这根本不起作用，因此我们决定禁用自动迁移并仅允许基于代码的迁移。 我应该补充一点，我们从一个干净的数据库开始，没有来自所有自动迁移的“损坏” _MigrationsHistory 。
所以现在的工作流程是：
add-migration <Name>并使用update-database将其应用到他update-database 。 到目前为止，这运行良好。 然而，在今天之前，通常只有我进行迁移，其他人应用它们。 但是今天有来自三个开发人员的迁移。 我只是拉动了那些迁移，做了一个运行良好的update-database 。
我也对我自己的数据模型进行了更改，因此在update-database结束时它给了我一个警告，我仍然不是最新的，所以我做了add-migration <my migration> 。 然而，当它为迁移搭建脚手架时，它给了我已经应用于数据库的所有迁移的更改。 所以：它试图删除已经删除的列，尝试创建一个已经存在的表，等等。
怎么可能？ 我的假设是 EF 将只检查_MigrationsHistory表并找出表中尚不存在的迁移，并按名称中的时间戳排序一一应用这些迁移。 但显然不是，因为即使我撤消自己的更改并且我有一个干净的环境，它仍然会抱怨我的数据库与模型不同步。 但我只是提取了这些更改并将它们应用到我的数据库中。 它是同步的。 我也可以在_MigrationsHistory表中看到我刚刚应用的迁移。
我唯一能想到的是我向数据模型添加了一个不会导致数据库更改的属性（我向数据模型 Y 添加了一个List<X> ，其中 X 是一对多关系中的多个。这不会导致数据库更改，因为 X 已经有 Y 的外键）。 会是这样吗？ 如果是这样，那真的很脆弱，因为没有办法为此添加迁移，因为没有数据库更改，我也不知道如何解决这个问题。
我不确定如何处理这个问题，因为我当然可以编辑它的脚手架并删除已经应用于我的数据库的所有内容。 但是然后呢？ 我签入它然后其他一些开发人员收到相同的消息，即使在应用我的新更改后，他的数据库也不是最新的，搭建他自己的更改，获取相同的废话搭建，编辑它，签入然后下一个开发人员得到它。 它变成了一个恶性循环，类似于我们使用自动迁移时的情况，我认为我们已经通过切换到仅基于代码的方式解决了这个问题。 我现在不能相信它会做正确的事情，像这样工作是一场噩梦。
我还尝试过使用update-database -t:201211091112102_<migrationname>添加我从同事update-database -t:201211091112102_<migrationname>但无济于事。 它仍然给了我错误的脚手架。
那么我们在这里做错了什么，或者 EF 根本不是为这样的协作而构建的？
更新
我创建了一个可重现的测试用例，虽然为了模拟这个多用户/多数据库场景，它有点冗长。
https://github.com/JulianR/EfMigrationsTest/
拥有上述项目后的重现步骤（这些步骤也存在于代码中）：
上面是模拟三个用户，其中用户1初始化他的数据库，另外两个也使用他的初始化来创建他们的数据库。 然后用户 2 和用户 3 都对数据模型进行自己的更改，并将其与应用更改所需的迁移一起添加到源代码管理中。 然后用户 1 拉取用户 2 和 3 的更改，而用户 1 自己也对数据库进行了更改。 然后，用户 1 调用update-database来应用用户 2 和 3 的更改。然后他搭建自己的迁移，然后错误地将用户 2 或 3 的更改添加到搭建的迁移，这在应用于用户 1 的数据库时会导致错误。
您需要添加一个空白的“合并”迁移，它将重置 .resx 文件中最新迁移的快照。 使用 IgnoreChanges 开关执行此操作：
Add-Migration <migration name> -IgnoreChanges
看这里的解释
您需要像处理代码冲突一样手动解决迁移冲突。 如果更新并且有新的迁移，则需要确保上次迁移背后的元数据与当前模型匹配。 要更新迁移的元数据，请为其重新发出 Add-Migration 命令。
例如，在您的场景中的第 17 步（更新数据库）之前，您应该发出以下命令
Add-Migration M2
这将更新元数据以使其与您当前的模型同步。 现在，当您尝试添加 M3 时，它应该是空白的，因为您还没有进行任何进一步的模型更改。
选项 1：添加空白的“合并”迁移
- 确保本地代码库中的任何挂起的模型更改都已写入迁移。 此步骤可确保您在生成空白迁移时不会错过任何合法更改。
- 与源代码管理同步。
- 运行 Update-Database 以应用其他开发人员已签入的任何新迁移。 ** 注意：****如果您没有从 Update-Database 命令收到任何警告，则说明没有来自其他开发人员的新迁移，并且有无需执行任何进一步合并。
- 运行 Add-Migration –IgnoreChanges（例如 Add-Migration Merge –IgnoreChanges）。 这会生成包含所有元数据（包括当前模型的快照）的迁移，但将忽略在将当前模型与上次迁移中的快照进行比较时检测到的任何更改（意味着您将获得空白的 Up 和 Down 方法）。
- 继续开发，或提交到源代码控制（当然是在运行单元测试之后）。
选项 2：更新上次迁移中的模型快照
- 确保本地代码库中的任何挂起的模型更改都已写入迁移。 此步骤可确保您在生成空白迁移时不会错过任何合法更改。
- 与源代码管理同步。
- 运行 Update-Database 以应用其他开发人员已签入的任何新迁移。 ** 注意：****如果您没有从 Update-Database 命令中收到任何警告，则说明没有来自其他开发人员的新迁移，并且有无需执行任何进一步合并。
- 运行 Update-Database –TargetMigration（在我们一直遵循的示例中，这将是 Update-Database –TargetMigration AddRating）。 这使数据库恢复到最后一次迁移的状态——有效地“取消应用”数据库中的最后一次迁移。 ** 注意：****需要此步骤以确保编辑迁移的元数据安全，因为元数据也存储在数据库的 __MigrationsHistoryTable 中。 这就是为什么如果最后一次迁移仅在您的本地代码库中，您应该只使用此选项。 如果其他数据库应用了上次迁移，您还必须回滚它们并重新应用上次迁移以更新元数据。
- 运行 Add-Migration（在我们一直遵循的示例中，这类似于 Add-Migration 201311062215252_AddReaders）。 ** 注意：****您需要包含时间戳，以便迁移知道您要编辑现有迁移而不是构建新迁移。 这将更新上次迁移的元数据以匹配当前模型。 命令完成后，您将收到以下警告，但这正是您想要的。 “仅重新构建了迁移的设计器代码 '201311062215252_AddReaders'。 要重新构建整个迁移，请使用 -Force 参数。”
- 运行 Update-Database 以使用更新的元数据重新应用最新的迁移。
- 继续开发，或提交到源代码控制（当然是在运行单元测试之后）。
MSDN 在这方面有一篇很棒的文章。 请通过它。
我们在我们的环境中遇到了类似的问题，以下是我们迄今为止发现的问题以及我们如何解决它：
如果您有已应用的更改（更新数据库）但未签入，然后您从另一个没有更改的开发人员那里收到更改，这就是事情似乎不同步的地方。 根据我们的经验，当您执行更新数据库过程时，似乎为您自己的更改保存的元数据会被其他开发人员的元数据覆盖。 其他开发人员没有您的更改，因此保存的元数据不再是您数据库的真实反映。 当 EF 在此之后进行比较时，它“认为”您的更改实际上又是新的，因为元数据更改。
一个简单的、公认的丑陋的解决方法是进行另一次迁移，并清除它的内容，这样你就有了空的 up() 和空的 down() 方法。 应用该迁移并将其签入源代码管理，让每个人都同步到该迁移。 这只是同步所有元数据，因此每个人都可以考虑所有更改。
我在 codeplex 上添加了一个问题，这个问题在我们的团队中也引起了很多人的注意。
我对此进行了一些思考，我希望我能对这里提出的不同意见和做法做出贡献。
考虑一下您的本地迁移实际代表什么。 在本地使用开发数据库时，在向表中添加列等、添加新实体等时，我使用迁移以最方便的方式更新数据库。
因此，Add-Migration 根据我之前的模型（模型 a）检查我当前的模型（我们称之为模型 b），并生成从数据库中的 a => b 开始的迁移。
对我来说，尝试将我的迁移与其他任何人的迁移合并是没有意义的，如果每个人确实有自己的数据库，然后在组织中存在某种阶段/测试/开发/生产数据库服务器。 这一切都取决于团队的设置方式，但如果您想真正以分布式方式工作，那么将彼此与其他人所做的更改隔离开来是有意义的。
好吧，如果您分布式工作并且有一些实体，例如，您正在处理的人员。 出于某种原因，很多其他人也在研究它。 因此，您可以根据需要为冲刺中的特定故事添加和删除 Person 上的属性（我们都在这里敏捷工作，不是吗？）那个明亮，然后到一个字符串等。
您添加名字和姓氏。
然后你就完成了，你有十次奇怪的上下迁移（你可能在工作时删除了其中的一些，因为它们只是废话）并且你从中央 Git 存储库中获取一些更改。 哇。 你的同事鲍勃也需要一些名字，也许你们应该互相谈谈？
不管怎样，他已经添加了NameFirst 和NameLast，我猜……那你怎么办？ 好吧，您合并、重构、更改以使其具有更合理的名称……例如 FirstName 和 LastName，您运行测试并检查他的代码，然后推送到中央。
但是迁移呢？ 好吧，现在是时候进行迁移，移动中央存储库，或者更具体地说，分支“测试”包含从其模型 a => 模型 b 的漂亮小迁移。 这次迁移将是一次且只有一次迁移，而不是十次奇怪的迁移。
你明白我在说什么吗？ 我们正在使用漂亮的小 pocos，它们的比较构成了实际的迁移。 所以，我们根本不应该合并迁移，在我看来，我们应该有每个分支的迁移或类似的东西。
事实上，我们甚至需要在合并后在分支中创建迁移吗？ 是的，如果这个数据库是自动更新的，我们需要。
另一件要考虑的事情是，在从中央仓库拉取数据之前，永远不要真正创建迁移。 这意味着你都得到其他团队成员的迁移代码和他们创建迁移之前模型的变化。
还得再努力一些，至少这是我对此的看法。
我能够想出的解决方案（至少对于 2 个用户，尚未测试 3 个）是：
up()和down()方法中所有生成的代码这仍将由更新数据库运行，但不会做任何事情，只是将元数据同步。
我同意@LavaEater。 问题的核心似乎是迁移脚手架应该集中化。 也许作为每次推送发生时某些自动化/集成构建过程的一部分？ 此后，团队成员可以从服务器中提取由此产生的迁移。
这意味着不应将他们自己的迁移脚本推送到服务器。
有一种简单的方法可以避免迁移发生合并冲突/错误。
migrations文件夹中删除所有 *.cs 文件。migrations文件夹中执行git checkout master ./* 。下面是执行步骤 3-6 的简单 Powershell 脚本：
function Write-Info($text)
{
Write-Color "$pwd", "> ", "$text" -Colour "Yellow", "Blue", "White"
}
function Create-Migration($project, $migrationName, $referenceBranch)
{
Set-Location "$SolutionPath\$project"
Write-Info "Going to migrations"
Set-Location "Migrations"
Write-Info "Removing ./*.cs"
Remove-Item ./*.cs
Write-Info "git fetch --all"
git fetch --all
Write-Info "git checkout origin/$referenceBranch ./*"
git checkout origin/$referenceBranch ./*
Set-Location ..
Write-Info "Creating migration $migrationName "
dotnet ef migrations add "$migrationName"
}
过去半年我一直在使用这种方法。 0 合并冲突要解决迁移时 8)。
Entity Framework Core 如何在生产环境中执行迁移
[英]Entity Framework Core how to execute migrations in production environment
Entity Framework Core 2.0中的迁移-如何指定环境或传递参数
[英]Migrations in Entity Framework Core 2.0 - How to specify environment or pass arguments
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.