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: http://wiki.apache.org/couchdb/History
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
www.jasondavies.com
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.
