CouchDB 对 _changes 请求的响应以这种格式返回： {"seq":12,"id":"foo","changes":[{"rev":"1-23202479633c2b380f79507a776743d5"}]}
我的问题 - 为什么“更改”元素是一个数组？什么情况下会在更改元素中返回多个项目？我从来没有在网上看到过一个包含超过一个项目的示例，而且根据我自己的经验，我只看到过一个项目。
我正在编写与更改交互的代码，我想了解如果实际上有多个项目该怎么办。
谢谢， 迈克
【问题讨论】：
标签： couchdb
更改元素是一个数组，用于反映文档的所有现有修订叶。如您所知，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。John 收到处于冲突状态的文档，并通过查看带有查询参数 style=all_docs 的更改提要查看下一个结果：
{“结果”：[ {"seq":3,"id":"thing","changes":[{"rev":"2-7051cbe5c8faecd085a3fa619e6e6337"},{"rev":"2-13839535feb250d3d8290998b8af17c3"}]} ], "last_seq":3}
虽然对文档的直接访问会返回他从获胜修订版中获得的数据（具有更高的 seq 号或只是最新的），但他可能会有许多冲突的修订版（想象一下单个文档的并发写入在十几个相互复制的数据库中） )
现在约翰决定解决这个冲突并更新实际修订，但放弃另一个：
{“结果”：[ {"seq":4,"id":"thing","changes":[{"rev":"3-2502757951d6d7f61ccf48fa54b7e13c"},{"rev":"2-13839535feb250d3d8290998b8af17c3"}]} ], "last_seq":4}
等等，Mike 的修订版还在吗？为什么？约翰惊慌失措地删除了他的文件：
{“结果”：[ {"seq":5,"id":"thing","changes":[{"rev":"2-13839535feb250d3d8290998b8af17c3"}{"rev":"4-149c48caacb32c535ee201b6f02b027b"}]} ], "last_seq":5}
现在他的文档版本已被删除，但他可以访问 Mike 的文档。
将 John 的更改从数据库 B 复制到数据库 A 都会带来墓碑：
{“结果”：[ {"seq":3,"id":"thing","changes":[{"rev":"3-2adcbbf57013d8634c2362630697aab6"},{"rev":"4-149c48caacb32c535ee201b6f02b027b"}]} ], "last_seq":3}
为什么会这样？因为这是关于他的数据“演变”的文档历史：在现实世界中，您的文档可能有许多中间叶子分布在大量数据库中，并且为了防止由于数据复制过程而导致无声数据覆盖，CouchDB 保留每个叶子以帮助解决此类冲突。您可以在 CouchDB wiki 中找到关于 replication and conflicts 的更多且可能更好的解释。那里也描述了更改提要query parameters。
【讨论】：