CouchDB 版本控制策略答案

【问题标题】：CouchDB versioning strategyCouchDB 版本控制策略
【发布时间】：2009-08-26 11:02:44
【问题描述】：

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

拥有一份原始文档，其中类型字段名为 example_original。

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

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

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

我应该提到我的用例将涉及对原始用例的有限数量的更改。大多数更新将包含新的原始文档。虽然这是我当前的用例，但如果涉及到许多更改，我也会对可能导致的问题感兴趣。

您认为这种方法的优缺点是什么？

【问题讨论】：

【解决方案1】：

使用 CouchDB 进行版本控制的策略是永远不要压缩包含您需要保留完整历史记录的文档的数据库。您仍然可以压缩其他数据库。这种简单的策略如今与编辑冲突解决策略一起开箱即用。

可以通过编写没有内容但设置已删除属性的新版本来删除文档。

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

现在看看 CouchDB 可能的未来：

【讨论】：

一个有趣的想法，但不是好的建议。虽然您可以通过简单地避免压缩来实现一个非常简单的版本控制系统，但您将使用数据库而不是使用它。最好使用不同的 _id 存储您要保留的每个版本，以便数据库知道必须保存它。
@NickPerkins，我特别提到不要压缩“那个”数据库，这意味着您可能有一个或多个其他数据库，您仍然会压缩。因此，此解决方案不适用于数据库。

【解决方案2】：

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

您是否需要从历史记录中删除某些内容？你真的确定吗？真的，真的确定？分支呢？

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

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

每个文档都有一个“历史文档”可以更快地导航历史，但父指针更“安全”（因为您不能轻易地用它们创建非法结构）。
当您创建新修订时，请重复使用 UUID 并分配一个新的唯一版本。更新历史文档或父指针。

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

【讨论】：

【解决方案3】：

Simple Document Versioning with CouchDB

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

【讨论】：

【解决方案4】：

这些文件的商业状态如何，尤其是合法的？我曾在您的提案从商业角度不合适的情况下工作，因为需要证明以 v.3 呈现的文档确实是文档的版本 3。动态应用增量不会降低合规性。

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

【讨论】：