couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <>
Subject Re: History Proposal
Date Fri, 31 Jul 2009 13:13:57 GMT

On Jul 31, 2009, at 7:24 AM, 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!
> Any comments on the above, please reply, and feel free to edit the  
> Wiki page.
> Thanks,
> --
> Jason Davies

Should be able to be enabled or disabled in the configuration.  Would  
need to think about what happens if you disable it and then reenable  
it.  It would likely be nice if you would just have a gap, but it  
would be essential that it is marked that there is a gap in the history.

The problem of rolling back the entire database sounds a lot like  
Apple's Time Machine.  Don't know how much of the technology around  
that is patented.

View raw message