在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。