0

使用 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”，从而在复制时导致冲突。

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

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

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

4

1 回答 1

0

基本上有两种情况：

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

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

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

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

如果您必须重新设计对 CouchDB 的访问，您可能会考虑更新处理程序以使未来的更改更加透明。

于 2013-10-30T17:45:51.970 回答