在CouchDB _changes响应中，为什么“更改”元素数组？

Question

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

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

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

谢谢， 迈克

Answer 1

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

1. 迈克在数据库中的已创建的文档和复制他的数据库B：

   { “成果”： { “序列”：1， “ID”： “东西”， “变化”：[{ “转”： “1-967a00dff5e02add41819138abb3284d”}]} ]， “last_seq”：1}

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

   { “结果”：[ { “SEQ”：2 “ID”： “东西”， “变更”：[{ “REV”： “2-7051cbe5c8faecd085a3fa619e6e6337”}]} ]， “last_seq”：2}

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

   {“results”：[{“seq”：2，“id”：“thing” “变化”：[{ “转”： “2-13839535feb250d3d8290998b8af17c3”}]} ]， “last_seq”：2}

4. 并再次复制他的数据库B.约翰接收冲突状态，通过观察变化的文档与查询参数养活style=all_docs看下结果：

   {“成果”： {“序列”：3，“ID”：“东西”，“变化”： [{ “REV”： “2-7051cbe5c8faecd085a3fa619e6e6337”}，{ “REV”： “2-13839535feb250d3d8290998b8af17c3”}]} ]， “last_seq”：3}

   尽管对文档直接访问返回从优胜他的数据修订版（具有更高的seq数或最新版本），他可能会有许多冲突的修订版（想象一下，在单个文档中并发写入的数据库在相互之间复制的数十个数据库中）

5. 现在约翰已决定解决这一冲突，并更新实际修订，但删除其他：

   {“成果”： {“序列”：4，“ID”：“东西”，“变化” ：[{ “转”： “3-2502757951d6d7f61ccf48fa54b7e13c”}，{ “转”： “2-13839535feb250d3d8290998b8af17c3”}]} ]， “last_seq”：4}

6. 等待中，迈克的修改仍然存在？为什么？约翰在恐慌中删除他的文件：

   { “成果”：[{ “序列”：5， “ID”： “东西”， “变化”：[{ “转”： “2-13839535feb250d3d8290998b8af17c3”} { “转”： “4-149c48caacb32c535ee201b6f02b027b”}]} ]， “last_seq”：5}

   现在，他的文件版本将被删除，但他能够访问到Mike的一个。

7. 复制约翰从数据库B数据库更改遗嘱所有带来的墓碑：

   { “成果”： { “序列”：3， “ID”： “东西”， “变化”： { “转”： “3-2adcbbf57013d8634c2362630697aab6”}，{ “转”： “4-149c48caacb32c535ee201b6f02b027b”}]} ]， “last_seq”：3}

   为什么会这样？因为这是关于他的数据“进化”的文档历史记录：在现实世界中，您的文档可能有许多中间分布在大量数据库中的叶子，并且为了防止由于数据复制过程导致静默数据覆盖，CouchDB会保留每个叶子以帮助解决此类冲突。更多，也许更好的解释，你可能会发现在CouchDB维基约replication and conflicts。此处还描述了更改源query parameters。