couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: History Proposal
Date Fri, 31 Jul 2009 13:22:09 GMT

On 31 Jul 2009, at 14:24, Jason Davies wrote:

> 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 easier.
> 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 database.
> 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!

I'd argue that if you need database snapshots, you replicate to a new  
database for every snapshot. The auto-history is more meant for undo  
of potentially disastrous actions.


View raw message