1. 首页
  2. 问答
  3. EF迁移问题

EF迁移问题

2013-04-02 171 views
2

我们在一个项目中使用EF迁移工作有3种状态：EF迁移问题

  • 发展：每个开发人员都有自己的数据库
  • 分期：同一个数据库生产
  • 生产：同一个数据库as staging

我们在开发中没有问题：我们已经改变了我们的DbContext和EF迁移改变了我们的数据库。每个开发人员都有正确的代码和正确的数据库。

当我们上传项目到分期时，问题出现了。我们需要更新升级数据库，因为

因为数据库创建

模型来头“XXX”环境已经改变，但如果我们更新数据库（使用迁移），生产投相同的消息（因为Production和Staging具有相同的数据库）。

数据库的更改很少，所以如果我们不使用EF迁移就没有问题。

有什么建议吗？

来源

2013-04-02 Subgurim

回答

1

也许是您在Staggig和Production中使用相同数据库的设计问题。

但

数据库的变化是微乎其微的

已经是不相同的数据库。当然你不能计算相同的散列值，即使在小变化=）

我认为这是它应该工作的方式。

我们还为每个开发者本地测试数据库提供了一些开发数据库 - 用于测试目的和生产力数据库。

而所有这三者都是不同的实例。

来源

2013-04-02 11:36:30 MikroDel

+1

是我期待的答案：d #thanks – Subgurim

+0

很乐意帮助你=） – MikroDel

2

我知道这已经被回答了 - 但只是为了增加对“历史的目的”和其他人可能会看到这...

，你所拥有的情景 - 同时支持Production和Staging支持与同数据库 - 从Migrations的角度来看有点问题。

您可以取消迁移 - 删除迁移表（__MigrationHistory）并同步事物（请参阅下面的帖子以获取更多信息） - 但有两个代码库指向相同的Db表示one migration table - 除非代码是相同（迁移方式），它将无法工作。所以唯一的解决方案是关闭迁移。

但是，隧道尽头似乎有一道光线。

来自EF（EF6预发行版）的新版本有Code First Migrations History Table Customization。

我没有设法时间尚未与该打，但是...
它的意思是 - 简单地说，你可以定制你的Configuration并覆盖IHistoryContextFactory。 这又可以让您重命名迁移表。

对于更复杂的场景 - 像你 - 这可能是一个解决方案

注意，它没有得到证实 - 但我想，他们把它放在那里 对于那些非常的原因。

A“伪解决方案”是这样的......

  • 使两个工厂 - 用于分期和生产 - 每个创建不同的“迁移表”，
  • 每个部署 - 都有自己的迁移（在代码中） - 和数据库中的迁移历史记录，
  • 您可以手动调整特定的“迁移表”升级 - 如果需要的话 - W/O损害其他
  • 确保你的数据库是“足够相似”这样既码/迁移可以运行并排侧

可以工作，我想。 ..

How to Synchronize Db/Code - Summary
How to Synchronize Db/Code - Long Version

来源

2013-04-02 14:30:14 NSGaga

+0

似乎有趣的极端！谢谢 ;） – Subgurim

相关问题

 相关问题