CouchDB versioning strategy

Question

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?

Adley

Are you trying to version the document contents or the document structure? – Mccomb

Only the content. Fields will never be deleted only added. – Adley

Answer 1

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.

Lorelle

See your point, thanks for the suggestion. I will never need to delete something from history, but some changes might be marked as "error" or similar. Support for branching will not be needed. – Adley

Answer 2

Simple Document Versioning with CouchDB

The versioning as attachments approach described in this article should fit most people's requirements for versioning.

Propman

the links is no longer live, but this one contain overview of the 4 methods described – Porcine

I believe this is an updated link – Hulse

@BrianPutt: The link you give is talking about CouchBase, which is different from CouchDB couchbase.com/couchbase-vs-couchdb – Isolecithal

Answer 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.

Future

I don't think this will represent a compliance problem, as long as one has an audit log for all docs including change docs. The approach is analogous to that of a original contract and subsequent amendments. – Adley

Answer 4

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:

• Today each revision holds a full copy of the document but one could think that optimizations of the CouchDB engine could one day store deltas.
• It is also possible that in the future CouchDB would offer an API to prevent the compaction of certain document types. This would allow to keep all the documents in the same database. This would be an easy patch to CouchDB.
• This strategy does enable the management of document branches but considering the nature of CouchDB as a document database, this is something of a reasonable, yet long term, possibility.

Cristophercristy

An interesting idea, but not good advice. While you could implement a very simple versioning system by simply avoiding compaction, you would be working against the database instead of working with it. Better to store each version that you want to keep with a different _id, so that the database knows that it must be saved. – Kelby

@NickPerkins, I have specifically mentioned to not compact "the" database which .. That implies that you may have one or more other databases that you would still compact. Therefore this solution does not work against the database. – Cristophercristy