CouchDB 版本控制策略
以下是实现版本控制的可行策略（使用“example”作为示例文档类型）：
拥有一个原始文档，其中类型字段名为 example_original。
对文档的后续更改都以 example_change 类型和 example_original 文档的 id 作为键。该更改还将带有时间戳。
保留一份类型为 example_current 的文档，该文档是 example_original 的结果，并且所有 example_change 均“已应用”。新的 example_change 文档将自动应用到该文档。
查找特定版本包括检索 example_original 文档并应用所需的更改（主要是达到某个时间戳，但也可能是许多更改）。
我应该提到，我的用例将涉及对原始用例的有限数量的更改。大多数更新将包含新的原始文档。虽然这是我当前的用例，但我也会对涉及许多更改时可能导致的问题感兴趣。
您认为这种方法有哪些优点和缺点？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
使用 CouchDB 进行简单文档版本控制< /a>
本文中描述的以附件形式进行版本控制的方法应该可以满足大多数人对版本控制的要求。
Simple Document Versioning with CouchDB
The versioning as attachments approach described in this article should fit most people's requirements for versioning.
我的第一个担心是：当“获取”某个版本时，是否可以在不修改数据库的情况下将更改应用到原始版本？
您是否需要从历史记录中删除某些内容？你真的确定吗？真的、真的确定吗？分支机构怎么样？
总而言之，这看起来是一个复杂的策略。请记住，我听说过 CouchDB，但从未使用过它。我会采用更简单的方法：
当您创建文档时，您会分配一个 UUID。不要使用该名称，否则您将在重命名操作期间遇到麻烦。添加一个显示为“1”的版本字段。创建第二个文档，其中包含具有相同 UUID 的文档列表，或添加指向第一个文档的“父”指针。
每个文档都有一个“历史文档”可以更快地导航历史记录，但父指针更“安全”（因为您无法轻松地使用它们创建非法结构）。
当您创建新版本时，请重复使用 UUID 并分配一个新的、唯一的版本。更新历史文档或父指针。
该策略实施起来非常简单，并且允许以后提供各种灵活性。您可以轻松删除部分历史记录，重命名很简单，并且可以创建分支。
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:
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).
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.
这些文件的业务状况如何，尤其是合法的？我曾经遇到过从业务角度来看您的提案不合适的情况，因为需要证明 v.3 所提供的文档确实是该文档的版本 3。动态应用增量不会降低合规性要求。
正如您所说，如果对文档的更改不频繁，那么您将不会通过存储增量而不是整个文档来节省太多磁盘空间。存储整个文档还可以可靠地预测任何文档的检索时间。它还降低了检索过程的复杂性。
What is the business status of these documents, especially legal? I have worked in situations where your proposal would not be appropriate from a business persepctive, because of a need to prove that the document presented as v.3 really is version 3 of the document. Dynamically applying deltas would not cut the compliance mustard.
If, as you say, changes to documents ae infrequent, then you are not going to be saving much disk space by storing deltas instead of whole documents. Storing whole documents also allows for the reliable prediction of the retrieval time for any document. It also reduces the complexity of the retrieval process.
使用 CouchDB 进行版本控制的策略是永远不要压缩包含需要保留完整历史记录的文档的数据库。您仍然可以压缩其他数据库。如今，这个简单的策略与编辑冲突解决策略一起开箱即用。
删除文档可以通过编写一个没有内容但删除了属性集的新版本来完成。
分支不能以这种方式完成，因为版本控制机制提供单个修订线程。
现在谈谈 CouchDB 可能的未来：
A strategy for versioning with CouchDB is to NOT ever compact the database which contains the documents for which you need to keep a full history. You could still compact other databases. This simple strategy works today out of the box with an edit conflict resolution strategy.
Deleting a document could be done by writing a new version with no content but a deleted property set.
Branches cannot be done this way because the versioning mechanism offers a single thread of revisions.
Now for the possible future of CouchDB: