在CouchDB _changes响应中，为什么"changes“元素是数组？

Question

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

我的问题是-为什么"changes“元素是一个数组？什么场景会在changes元素中返回多个项目？我从来没有在网上看到过超过一个项目的例子，根据我自己的经验，我只看到过一个项目。

我正在编写与更改交互的代码，我想知道如果实际上有多个项目，该怎么做。

谢谢，迈克

Answer 1

changes元素是一个数组，用来反映文档中所有已存在的修订页。如你所知，CouchDB不会完全删除文档，而是设置gravestone，以防止他在从具有尚未删除的旧版本的源进行复制后意外复活。此外，由于复制后发生的更新冲突，可能会有多个leafs。例如：

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

{"results":[ {"seq":1，"id":"thing"，"changes":{"rev":"1-967a00dff5e02add41819138abb3284d"}} ]，"last_seq":1}

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

{"results":[ {"seq":2，"id":"thing"，"changes":{"rev":"2-7051cbe5c8faecd085a3fa619e6e6337"}} ]，"last_seq":2}

• But在同一时间也在数据库A中为他做了一些更改(忘记清理数据或添加重要的东西)：

{"results":[ {"seq":2，"id":"thing"，"changes":{"rev":"2-13839535feb250d3d8290998b8af17c3"}} ]，"last_seq":2}

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

{"results":[ {"seq":3，"id":"thing"，"changes":{"rev":"2-7051cbe5c8faecd085a3fa619e6e6337"}，{"rev":"2-13839535feb250d3d8290998b8af17c3"}} ]，"last_seq":3}

虽然直接访问document会从wining修订版返回数据(具有更高的序列号或只有最新版本)，但他可能会有许多冲突的修订版(想象一下在十几个相互复制的数据库中对单个文档进行并发写入)

• 现在决定解决这个冲突并更新实际的修订版，但放弃另一个：

{"results":[ {"seq":4，"id":"thing"，"changes":{"rev":"3-2502757951d6d7f61ccf48fa54b7e13c"}，{"rev":"2-13839535feb250d3d8290998b8af17c3"}} ]，"last_seq":4}

• Wait，的麦克风版本还在吗？为什么？约翰惊慌失措地拿出他的文件：

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

现在他的文档版本被删除了，但他能够访问迈克的one.

• Replicating约翰从数据库B到数据库A的更改都将带来tombstone：

{"results":[ {"seq":3，"id":"thing"，"changes":{"rev":"3-2adcbbf57013d8634c2362630697aab6"}，{"rev":"4-149c48caacb32c535ee201b6f02b027b"}} ]，"last_seq":3}

为什么会这样呢？因为这是文档历史上关于他的数据的“进化”：在现实世界中，你的文档可能有许多中间叶分布在大量的数据库中，为了防止静默的数据覆盖，在数据复制过程中，CouchDB保留每一片叶来帮助解决这样的冲突。你可以在CouchDB维基上找到更多关于replication and conflicts的更好的解释。这里还描述了对feed query parameters的更改。