CouchDB版本控制策略

Question

以下是实施版本控制的可行策略（使用“example”作为示例文档类型）：

有一个原始文档，其中type字段名为example_original。

对文档的后续更改都具有类型example_change和example_original文档的id作为键。此更改还将带有时间戳。

保留一个类型为example_current的doc，它是example_original的结果，所有example_change都是“applied”。新的example_change文档将自动应用于此文档。

查找特定版本将包括检索example_original文档并应用所需的更改（主要是某个时间戳，但也可能是一些更改）。

我应该提一下，我的用例将涉及对原文的有限修改。大多数更新将包含新的原始文档。虽然这是我目前的用例，但我也会对涉及许多变化的问题感兴趣。

您在这种方法中看到了哪些优点和缺点？

Answer 1

Simple Document Versioning with CouchDB

本文中描述的作为附件方法的版本控制应符合大多数人对版本控制的要求。

Answer 2

我首先担心的是：当“获取”某个版本时，您是否可以在不修改数据库的情况下将更改应用于原始版本？

您是否需要删除历史记录中的内容？你真的相信吗？真的，真的很确定吗？分支怎么样？

总而言之，这看起来像一个复杂的策略。请记住，我听说过CouchDB但从未使用它。我会采用更简单的方法：

1. 创建文档时，您可以分配UUID。不要使用名称，否则在重命名操作期间会遇到麻烦。添加一个读取“1”的版本字段。创建第二个文档，其中包含具有相同UUID的文档列表，或者向第一个文档添加“父”指针。

   每个文档都有一个“历史文档”，可以更快地导航历史记录，但父指针更“安全”（因为你不能轻易地用它们创建非法结构）。

2. 创建新修订时，请重复使用UUID并分配新的唯一版本。更新历史记录文档或父指针。

这种策略实施起来非常简单，以后可以提供各种灵活性。您可以轻松删除部分历史记录，重命名很简单，并且可以创建分支。

Answer 3

这些文件的业务状况如何，尤其是合法的？我曾在一些情况下工作过，因为需要证明提交给v.3的文档确实是文档的第3版。动态应用增量不会削减合规性芥末。

正如您所说，如果对文档的更改很少，那么您不会通过存储增量而不是整个文档来节省大量磁盘空间。存储整个文档还允许可靠地预测任何文档的检索时间。它还降低了检索过程的复杂性。

Answer 4

使用CouchDB进行版本控制的策略是不要压缩包含您需要保存完整历史记录的文档的数据库。你仍然可以压缩其他数据库。这个简单的策略现在可以通过编辑冲突解决策略开箱即用。

删除文档可以通过编写没有内容但删除了属性集的新版本来完成。

分支不能以这种方式完成，因为版本控制机制提供了单个修订线程。

现在为CouchDB的可能未来：

• 今天，每个版本都包含该文档的完整副本，但人们可能会认为CouchDB引擎的优化有一天会存储增量。
• 将来CouchDB也可能会提供一个API来防止某些文档类型的压缩。这样可以将所有文档保存在同一个数据库中。这对CouchDB来说是一个简单的补丁。
• 这种策略确实能够管理文档分支，但考虑到CouchDB作为文档数据库的性质，这是一种合理但长期的可能性。