CouchDB版本控制策略

Question

以下是實現版本控制的可行策略（使用“example”作為示例文檔類型）：

有一個原始文檔，其中類型字段名為example_original。

對文檔的后續更改都具有類型example_change和example_original文檔的id作為鍵。 此更改還將帶有時間戳。

保留一個類型為example_current的doc，它是example_original的結果，所有example_change都是“applied”。 新的example_change文檔將自動應用於此文檔。

查找特定版本將包括檢索example_original文檔並應用所需的更改（主要是某個時間戳，但也可能是一些更改）。

我應該提一下，我的用例將涉及對原始的有限數量的更改。 大多數更新將包含新的原始文檔。 雖然這是我目前的用例，但我也會對可能導致許多變更的問題感興趣。

你在這種方法中看到了什么利弊？

Answer 1

使用CouchDB進行簡單文檔版本控制

本文中描述的作為附件方法的版本控制應該適合大多數人對版本控制的要求。

Answer 2

我首先擔心的是：當“獲取”某個版本時，您是否可以在不修改數據庫的情況下將更改應用於原始版本？

你需要從歷史中刪除一些東西嗎？ 你真的相信嗎？ 真的，真的很確定嗎？ 分支怎么樣？

總而言之，這看起來像一個復雜的策略。 請記住，我聽說過CouchDB但從未使用它。 我會采用更簡單的方法：

1. 創建文檔時，您可以分配UUID。 不要使用名稱，否則在重命名操作期間會遇到麻煩。 添加一個讀取“1”的版本字段。 創建第二個文檔，其中包含具有相同UUID的文檔列表或添加指向第一個文檔的“父”指針。

   每個文檔具有“歷史文檔”允許更快地導航歷史，但父指針更“安全”（因為您不能輕易地使用它們創建非法結構）。

2. 創建新修訂時，請重用UUID並分配新的唯一版本。 更新歷史記錄文檔或父指針。

這種策略實現起來非常簡單，以后可以提供各種靈活性。 您可以輕松刪除部分歷史記錄，重命名很簡單，您可以創建分支。

Answer 3

這些文件的業務狀況是什么，尤其是合法的？ 我曾在一些情況下工作過，因為需要證明提交給v.3的文檔確實是文檔的第3版。 動態應用增量不會削減合規芥子氣。

正如你所說，如果對文檔的更改很少，那么你不會通過存儲增量而不是整個文檔來節省大量磁盤空間。 存儲整個文檔還允許可靠地預測任何文檔的檢索時間。 它還降低了檢索過程的復雜性。

Answer 4

使用CouchDB進行版本控制的策略是不要壓縮包含您需要保存完整歷史記錄的文檔的數據庫。 你仍然可以壓縮其他數據庫。 這個簡單的策略現在可以通過編輯沖突解決策略開箱即用。

刪除文檔可以通過編寫沒有內容但刪除了屬性集的新版本來完成。

分支不能以這種方式完成，因為版本控制機制提供單個修訂線程。

現在為CouchDB的可能未來：

• 今天，每個版本都保存了該文檔的完整副本，但人們可能會認為CouchDB引擎的優化有一天會存儲增量。
• 將來CouchDB也可能提供API來防止某些文檔類型的壓縮。 這樣可以將所有文檔保存在同一個數據庫中。 這對CouchDB來說是一個簡單的補丁。
• 這種策略確實能夠管理文檔分支，但考慮到CouchDB作為文檔數據庫的性質，這是一種合理但長期的可能性。