CouchDB版本控制策略 [英] CouchDB versioning strategy

问题描述

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

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

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

保留一个文档，其类型为example_current，这是example_original的结果，其中所有example_change为 applied。新的example_change文档将自动应用于此文档。

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

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

解决方案

我首先担心的是：某个版本，是否可以在不修改数据库的情况下将更改应用到原始版本？

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

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

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

   
   

   具有历史文档。每个文档允许历史的更快导航，但是父指针更安全。 （因为您不能轻易使用它们创建非法结构）。

   
   



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

   
   

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

Would the following be a viable strategy for implementing versioning(using "example" as a sample document type):

Have one original document where the type field is named example_original.

Subsequent changes to the document all have type example_change and the id of example_original document as a key. The change would also carry a timestamp.

Keep one doc with type example_current that is the result of example_original with all example_change "applied". A new example_change document would automatically be applied to this document.

Finding a specific version would consist in retrieving the example_original doc and applying the desired changes (mostly up to a certain timestamp, but it could also be a number of changes).

I should mention that my use-case will involve a limited number of changes to the original. Most updates will consist of new original documents. While this is my current use-case I would also be interested in issues that would result if many changes where involved.

What pros and cons do you see in this approach?

解决方案

My first worry is: When "getting" a certain version, can you apply the changes to the original without modifying the database?

Will you ever need to delete something from the history? Are you really sure? Really, really sure? How about branches?

All in all, this looks like a complex strategy. Keep in mind that I've heard about CouchDB but never used it. I'd go for a more simple approach:

1. When you create a document, you assign a UUID. Don't use the name or you'll run into trouble during rename operations. Add a version field that reads "1". Create a second document which contains a list of documents with the same UUID or add a "parent" pointer to the first document.

   Having a "history document" per document allows for faster navigation of the history but parent pointers are more "safe" (since you can't easily create illegal structures with them).

2. When you create a new revision, reuse the UUID and assign a new, unique version. Update the history document or the parent pointer.

This strategy is pretty simple to implement and allows all kinds of flexibility later. You can erase parts of the history easily, rename is simple, and you can create branches.

这篇关于CouchDB版本控制策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！