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

Question

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

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

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

谢谢，
麦克风

Answer 1

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

Mike 在数据库 A 中创建了文档并将其复制到数据库 B:

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

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

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

但与此同时，Mike 还在数据库 A 中为他做了一些更改(忘记清理数据或添加一些重要的东西):

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

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

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

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

现在约翰决定解决这个冲突并更新实际修订，但放弃另一个:

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

等等，Mike 的版本还在吗？为什么？约翰 panic 地删除了他的文件:

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

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

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

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

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