5

CouchDB 对 _changes 请求的响应以这种格式返回： {"seq":12,"id":"foo","changes":[{"rev":"1-23202479633c2b380f79507a776743d5"}]}

我的问题 - 为什么“更改”元素是一个数组？什么情况下会在更改元素中返回多个项目？我从来没有在网上看到过一个包含超过一个项目的示例，而且根据我自己的经验，我只看到过一个项目。

我正在编写与更改交互的代码，并且我想了解如果实际上有多个项目该怎么办。

谢谢，迈克

4

1 回答 1

8

changes 元素是一个数组，用于反映文档的所有现有修订叶。如您所知，CouchDB 不会完全删除文档，而是设置墓碑以防止他在从具有尚未删除的旧版本的源复制后意外复活。由于复制后发生的更新冲突，也可能有多个叶子。例如：

  1. Mike 在数据库 A 中创建了文档并将他复制到数据库 B：

    {"结果":[ {"seq":1,"id":"thing","changes":[{"rev":"1-967a00dff5e02add41819138abb3284d"}]} ], "last_seq":1}

  2. John 已收到您的文档并在数据库 B 中更新了他：

    {"结果":[ {"seq":2,"id":"thing","changes":[{"rev":"2-7051cbe5c8faecd085a3fa619e6e6337"}]} ], "last_seq":2}

  3. 但与此同时，Mike 也在数据库 A 中为他做了一些更改（忘记清理数据或添加一些重要的东西）：

    {"结果":[ {"seq":2,"id":"thing","changes":[{"rev":"2-13839535feb250d3d8290998b8af17c3"}]} ], "last_seq":2}

  4. 并再次将他复制到数据库 B。John 收到处于冲突状态的文档，并通过查看带有查询参数的更改提要style=all_docs查看下一个结果：

    {"结果":[ {"seq":3,"id":"thing","changes":[{"rev":"2-7051cbe5c8faecd085a3fa619e6e6337"},{"rev":"2-13839535feb250d3d8290998b8af17c3"}] } ]，“last_seq”：3}

    虽然直接访问文档会从获胜修订版（具有更高的 seq 号或只是最新的）返回他的数据，但他可能会有许多冲突的修订版（想象在十几个相互复制的数据库中并发写入单个文档）

  5. 现在 John 决定解决这个冲突并更新实际修订，但放弃另一个：

    {"结果":[ {"seq":4,"id":"thing","changes":[{"rev":"3-2502757951d6d7f61ccf48fa54b7e13c"},{"rev":"2-13839535feb250d3d8290998b8af17c3"}] } ]，“last_seq”：4}

  6. 等等，迈克的修订版还在吗？为什么？约翰惊慌失措地删除了他的文件：

    {"结果":[ {"seq":5,"id":"thing","changes":[{"rev":"2-13839535feb250d3d8290998b8af17c3"}{"rev":"4-149c48caacb32c535ee201b6f02b027b"}]} ], "last_seq":5}

    现在他的文档版本已被删除，但他可以访问 Mike 的文档。

  7. 将 John 的更改从数据库 B 复制到数据库 A 都会带来墓碑：

    {"结果":[ {"seq":3,"id":"thing","changes":[{"rev":"3-2adcbbf57013d8634c2362630697aab6"},{"rev":"4-149c48caacb32c535ee201b6f02b027b"}] } ]，“last_seq”：3}

    为什么这样？因为这是关于他的数据“演变”的文档历史：在现实世界中，您的文档可能有许多中间叶子分布在大量数据库中，并且为了防止由于数据复制过程而导致无声数据覆盖，CouchDB 保留每个叶子以帮助解决此类冲突。您可以在 CouchDB wiki 中找到更多且可能更好的关于复制和冲突的解释。那里也描述了更改提要查询参数。

于 2013-02-13T02:06:24.403 回答