NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



Document Versioning in CouchDB

Just because CouchDB uses Multi Versioning Concurrency Control (or MVCC[1]) doesn’t mean that you’ll also get document versioning support by default. So, how would you go if you need document versioning in CouchDB?

This article takes a look at 4 different approaches and details the first one as it looks to be both simple, scalable and supported by CouchDB replication:

  1. storing as a binary attachment the previous version
  2. append old versions to an array embedded in the current document
  3. keep each version as a separate document
  4. skip compaction

How does storing previous document version as a binary attachment to the new version work?

[…] when the document is loaded from the CouchDB server, the string representation is saved before being parsed into JSON. Later, when the document is saved, the string representation is attached as a new binary attachment, with the corresponding rev as it’s name, and a content type of application/json. This way any CouchDB library can just open the stored rev, and see it as a normal document.

This means that each time the document is updated, the client will also store the previous version as an attachment to the latest version. At any time, a user can load any of the old versions.