couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Davies <>
Subject History Proposal
Date Fri, 31 Jul 2009 12:24:30 GMT
Hi all,

I've been discussing adding history support to CouchDB with Jan.  I've  
been collecting our thoughts here:

Probably the #1 misconception for newcomers is that the "_rev" member  
in documents should be used for version control i.e. giving clients  
the ability "roll back" in time and view a document's state at some  
point in the past.  We all know that when compaction occurs old  
revisions of documents are effectively deleted hence we tell people  
off whenever they suggest that the MVCC revisions concept is just like  
git and can be used as a VCS.  We usually recommend people roll their  
own system on top of CouchDB, which would involve writing a  
dbupdatenotification handler to listen for changes and push them into  
a separate db.

Many would still love to have built-in support for history in CouchDB,  
and for good reason, as most applications would benefit hugely from  
being able to support "undo" for free to prevent potentially  
catastrophic data loss if someone presses the wrong button.

The main points of this proposal are:

1. Store the historical versions of documents in a separate database.   
This is for a number of reasons: a) keeping it separate means we don't  
clog up the main database with historical data b) history-specific  
views can be kept here c) non-intrusive implementation of this is  
2. The change will be made at the couch_db layer so that *any* change  
to any document in the target database will be mirrored to the history  
3. Each and every change to a document will result in a new document  
being created in the history database (with a new ID) containing an  
exact copy of that document e.g. {_id: <new ID>, doc: <exact copy of  
doc> }.
4. Adding meta-data to changes can be handled by a custom _update  
handler (yet to be developed) to set fields such as "last_modified"  
and "last_modified_user".

One use case we'd like to support is effectively (from the point of  
the user) being able to "roll back" a view to a specific point in  
time, but how this would look in the history database has me stumped  
so far.  Rolling back a specific doc is easy, but multiple docs, not  
so easy it seems.  Any suggestions welcome!

Any comments on the above, please reply, and feel free to edit the  
Wiki page.

Jason Davies

View raw message