CouchDB 文档有 DAG 吗？
我正在看 CouchDB。文档有版本，并且您可能有冲突的版本。它是否像 dvcs 一样将版本序列存储为有向无环图 (DAG)？如果没有，是如何实施的？
I'm looking at CouchDB. Documents have versions, and you can have conflicting versions. Does it store the version sequence as a directed acyclic graph (DAG), like dvcs do? If not, how is it implemented?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，修订序列类似于有向无环图。我在 CouchDB 复制中讨论了这一点（在概念层面）就像 Git 一样。
我想说，出于教学目的，CouchDB 就像 Git。然而，也存在显着差异。仅举几例：
因此，我不确定是否可以实现 3 路合并在实践中，因为最多只有两个数据修订版可供使用：源和目标。人们将知道共同祖先的存在，但其价值却不会。
虽然这可能是一个问题一般，但有一些“作弊”使得它在实践中并没有那么糟糕。
validate_doc_update()函数可防止任意修改。它甚至可能要求将更改元数据存储为文档的一部分。 （但这是一个应用程序级的解决方案。），这些都是高度特定于应用的，而不是通用的解决方案。
Yes, the revision sequence is similar to a directed acyclic graph. I discussed this (at a conceptual level) in CouchDB replication is like Git.
I like to say that CouchDB is like Git for pedagogical purposes. However there are significant differences. To name a few:
Thus, I am unsure if you can achieve a 3-way merge in practice because at most you will have only two revisions of the data to work with: source and target. The common ancestor will be known to exist, but its value will not.
While this may be a problem in general there are several "cheats" that make it not so bad in practice.
validate_doc_update()function prevents arbitrary modifications. It can even require change metadata to be stored as part of the document. (But this is an application-level solution.)Obviously these are highly application-specific and are not general solutions.
您不能依赖 CouchDB 中的文档版本，保留它们只是为了在复制期间解决冲突。以前版本的文档会在压缩期间被删除。
CouchDB wiki 有关于此的更多详细信息。
You cannot rely on versions of documents in CouchDB, they are only kept to allow conflict resolution during replication. Previous versions of documents are deleted during compaction.
The CouchDB wiki has more details on this.