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?
Asked
Active
Viewed 188 times
2 Answers
3
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:
- CouchDB does not store the old data, just the old revision IDs
- CouchDB will ultimately truncate very long revision histories to retain performance
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.
- The
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.) - A large class of data for a large class of applications can be 2-way merged: e.g. choose the latest timestamp; merge dissimilar phone numbers into an array of phone numbers; etc.
Obviously these are highly application-specific and are not general solutions.
Community
- 1
- 1
JasonSmith
- 72,674
- 22
- 123
- 149
0
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.
Andrew Wilkinson
- 10,682
- 3
- 35
- 38
-
Hmm - The reason I was interested in getting a DAG was I was hoping to find a lca for a conflict revision, so that a 3-way merge could be done. But If I can't rely on been access the lca, then I can't use that. – Gary van der Merwe Oct 05 '11 at 10:35