如何在具有多个分支的项目中管理迁移? [英] How to manage Migrations in a project with multiple branches?

本文介绍了如何在具有多个分支的项目中管理迁移?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个 ASP.NET MVC3 项目,它使用 Entity Framework 4.3 和代码优先方法.我使用迁移来使数据库保持最新.

I have an ASP.NET MVC3 project that uses Entity Framework 4.3 with the code-first approach. I use Migrations to keep the database up-to-date.

该项目受源代码控制,我有多个分支.我刚刚意识到,当我想将我的一个分支合并到 master 时会出现问题.由于我在两个分支都创建了migration-files,合并的时候会出现migration重叠,可能会造成冲突.

The project is under source-control and I have a number of branches. What I just realized is that there will be a problem when I want to merge one of my branches into the master. Since I have created migration-files in both branches, there will be overlapping migrations when I merge, which will probably cause conflicts.

在具有多个分支的项目中是否有管理迁移的好方法?

Is there a good way to manage Migrations in a project with multiple branches?

更新

一种方法是合并,然后删除在分支分离时创建的所有迁移文件,然后创建一个新的迁移文件,该文件包含从创建分支到重新合并分支的所有更改.这将在开发环境中工作,您可以在其中转储数据库并使用所有迁移文件重新构建它.那么问题将是生活环境.由于您无法在没有丢失数据风险的情况下回滚到创建分支的时间,因此当您尝试使用新的迁移文件更新实时数据库时会发生冲突.

One way would be to merge, then delete all migration-files created while the branches were separate, and then create one new migration file that holds all changes from the time the branch was created until it was merged back in. This would work for the dev-environment where you can dump the database and re-build it with all the migration-files. The problem then would be the live-environment. Since you couldn't roll back to the time the branch was created without the risk of loosing data, there will be a conflict when you try to use your new migration-file to update the live database.

推荐答案

有一个在类似问题上处理实体框架迁移合并冲突的更好解决方案.

合并后您需要做的就是在目标分支中重新构建迁移的元数据.也就是说,您不需要重新构建 up/down 代码,而只是重新构建 resx 文件中的状态.

All you need to do after a merge is to re-scaffold the meta data of the migration in the target branch. That is you do not rescaffold the up/down code, just the state in the resx-file.

add-migration [the_migration_to_rescaffold_metadata_for]

这几乎总是有效.如果合并中的不同迁移改变了数据库,导致迁移不再可运行或产生意外结果,则该过程将失败.话虽这么说 - 我相信这是一种非常罕见的情况,因为大多数迁移应该是自动生成的,或者至少不依赖于迁移本身没有改变的其他表.

This almost always works. The procedure will fail if a different migration in the merge have changed the database in such a way that the migration is no longer runnable or gives an unexpected result. That being said - I believe that to be a very rare case as most migrations should be auto-generated, or at least not be dependent on other tables that are not changed in the migration itself as well.

脚手架状态失败的一种情况可能是:

One such case where rescaffold state would fail could be:

  • 列 foo 是一个整数,行包含 [0, 1, 2]

  • Column foo is an int and rows contain [0, 1, 2]

从分支 A 迁移 A 将 foo 更改为布尔值(0 将自动变为 false 并且 > 0会变成真的)

Migration A from branch A change foo to boolean (0 will become false automatically and > 0 will become true)

从分支 B 的迁移 B 将 foo 更改为字符串.它期望它是一个 int 但它是一个布尔值,但迁移会成功.数据将丢失,因为在创建迁移 B 时,行将包含 ["0", "1", "2"].当迁移 A 将列更改为布尔值(并成功完成并获得预期结果)时,行现在将包含 ["0", "1", "1"] 而迁移 B 将具有与观察到的不同的最终结果分支 B.

Migration B from branch B change foo to string. It expects it to be an int but it is a boolean, the migration will succeed though. Data will be lost since when migration B was created the rows would contain ["0", "1", "2"]. When migration A altered column to boolean (and did so successfully and with expected result) the rows will now contain ["0", "1", "1"] instead and Migration B will have a different end result than what was observed in Branch B.

可能存在更多边缘情况,解决方案可能会出错.但是,如果向上/向下迁移代码不依赖于合并中另一个迁移所更改的内容,则只需更新迁移中的元数据即可.

There are probably more edge cases where things could go wrong with the solution. But if migrations up/down code is not dependent on things changed by another migration in the merge it should work well to just update the metadata in the migrations.

这篇关于如何在具有多个分支的项目中管理迁移?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆