在两个 CouchDB 设计之间迁移答案

【问题标题】：Migrate between two CouchDB designs在两个 CouchDB 设计之间迁移
【发布时间】：2013-10-31 01:45:51
【问题描述】：

使用 TouchDB-iOS，我们有一个 iOS 应用程序，它有一个本地 CouchDB 文档存储，可以复制到云 CouchDB 服务器。我们有几个用户在运行这个应用程序，从而产生了一堆 TouchDB 数据库副本。

当我们开始使用该应用程序时，我们是 CouchDB 的新手（我们仍然是）。我们设计了一种关系，以便类型 A 的文档具有一个属性，即：这是一个字符串，描述了一个以逗号分隔的 id 列表，这些 id 是类型 B 的文档。

因此，使用 Employee/Employer 示例，Employer 有一个名为 employeeIds 的属性，即“1,7,8,10”。如果员工 10 退出，此列表将更新为“1,7,8”。

问题是，当在应用程序的另一个实例上，假设在另一部手机上，员工 7 将退出列表时，列表会更新为“1,8,10”，从而导致复制时发生冲突。

因此，我们认为更好的办法是在 Employee 文档属性中添加一个 employerId。如果员工辞职，我们只需将他的employerId 设置为空。这样的冲突会少很多吧？

我现在面临的问题是有多个应用程序，如何将所有 CouchDB 数据库从第一个设计迁移到第二个设计。

我是否需要淘汰所有旧应用程序，或者是否有一种故障安全方法可以将所有应用程序迁移到新设计而不破坏现有应用程序并最大限度地减少冲突？我应该如何最好地处理这种情况？

【问题讨论】：

【解决方案1】：

基本上有两种情况：

如果您的应用仅对数据库进行查询（通过视图），您可以简单地更新视图以同样使用“旧样式”和“新样式”文档。然后，您可以在后台更新您的文档（例如，通过_changes feed）并最终再次删除对旧式文档的支持。

如果您的应用程序使用应用程序的结构，那么也可能无法更新应用程序。否则，您需要在新旧样式文档之间转换一些代理，例如

CouchDB with new-style docs  <-- proxy application --> apps with old-style docs

当然，您可以更新您的应用以同时处理新旧样式的文档，这样您就可以逐步转换您的文档。

如果您必须重新设计对 CouchDB 的访问权限，您可以考虑使用update handlers 以使未来的更改更加透明。

【讨论】：