CouchDB对_changes请求的响应以以下格式返回：｛"seq"：12，"id"："foo"，"changes"：[｛"rev"："1-23202479633c2b380f79507a776743d5"]｝
我的问题是，为什么"changes"元素是一个数组？什么场景会在changes元素中返回多个项目？我从未在网上看到过一个不止一个项目的例子，根据我自己的经验，我只见过一个项目。
我正在编写与更改交互的代码，我想了解如果实际上有多个项目，该怎么办。
谢谢，Mike
changes元素是一个数组，用于反映文档中所有已存在的修订页。正如您所知，CouchDB并没有完全删除文档，而是设置了墓碑，以防止他在从有旧修订版的源复制后意外复活。此外，由于复制后发生的更新冲突，可能会有多个叶。例如：
-
Mike已经在数据库A中创建了文档，并将其复制到数据库B:
｛"结果"：[｛"seq"：1，"id"："thing"，"changes"：[｛"rev"："1-967a00dff5e02add41819138abb3284d"｝]，"lastrongeq"：1｝
-
约翰已经收到你的文件，并在数据库B:中更新了他的信息
｛"结果"：[｛"seq"：2，"id"："thing"，"changes"：[｛"rev"："2-7051cbe5c8faed085a3fa619e6e6337"｝]，"lastrongeq"：2｝
-
但与此同时，Mike在数据库A:中也为他做了一些更改（忘记清理数据或添加重要内容）
｛"结果"：[｛"seq"：2，"id"："thing"，"changes"：[｛"rev"："2-13839535feb250d3d8290998b8af17c3"]｝]，"lastrongeq"：2｝
-
并再次将其复制到数据库B中。John收到处于冲突状态的文档，通过查看带有查询参数
style=all_docs的更改提要，可以看到下一个结果：｛"结果"：[｛"seq"：3，"id"："thing"，"changes"：[｛"rev"："2-7051cbe5c8faed085a3fa619e6e6337"｝，｛"rev"："2-13839535feb250d3d8290998b8af17c3"｝]｝]，"lastrongeq"：3｝
虽然直接访问文档会从获胜的修订（seq编号更高或只是最新的）中返回他的数据，但他可能会有许多冲突的修订（想象一下，在相互复制的十几个数据库中同时写入单个文档）
-
现在，约翰决定解决这个冲突并更新实际修订，但放弃了另一个：
｛"结果"：[｛"seq"：4，"id"："thing"，"changes"：[｛"rev"："3-2502757951d6d7f61ccf48fa54b7e13c"｝，｛"rev"："2-13839535feb250d3d8290998b8af17c3"｝]｝]，"lastrongeq"：4}
-
等等，迈克的复习本还在吗？为什么？约翰惊慌失措地拿走了他的文件：
｛"结果"：[｛"seq"：5，"id"："thing"，"changes"：[｛"rev"："2-13839535feb250d3d8290998b8af17c3"｝]，"lastrongeq"：5}
现在他的文档版本被删除了，但他可以访问迈克的文档。
-
将John的更改从数据库B复制到数据库A将带来tombstone：
｛"结果"：[｛"seq"：3，"id"："thing"，"changes"：[｛"rev"："3-2adcbbf57013d8634c2362630697aab6"｝，｛"rev"："4-149c48caacb32c535ee201b6f02b027b"｝]｝]，"lastrongeq"：3｝
为什么会这样？因为这是关于他的数据"进化"的文档历史：在现实世界中，您的文档可能有许多中间叶，分布在大量数据库中，为了防止由于数据复制过程而导致的静默数据覆盖，CouchDB保留了每个叶，以帮助解决此类冲突。您可以在CouchDBwiki中找到更多关于复制和冲突的可能更好的解释。更改提要查询参数也在其中进行了描述。