3

Near as I can tell, CouchDB revisions are not to be treated like revisions in the document versioning sense of the word. From glancing at other posts, they seem to be regarded as transient data that exists until a coarse-grained compact operation is called.

My question is, if I am interested in using CouchDB to maintain documents, as well as a version-history of those documents, should I allow that to be handled natively by CouchDB revisions, or should I build a layer on-top that will survive a compact operation?

I am thinking the latter, simply because Couch does not replicate revisions of documents, only the latest update. This makes me think revision is a mis-leading name, as it's more of a data structure for stabilizing replication.

Jacob Groundwater
  • 6,581
  • 1
  • 28
  • 42
  • It looks like this may be the answer I was looking for http://stackoverflow.com/questions/2717591/is-it-really-wrong-to-version-documents-using-couchdbs-default-behaviour – Jacob Groundwater Nov 24 '11 at 22:41

1 Answers1

3

You must build that layer because couchdb revisions are not a versioning system for your data.

'revision' is misleading, and so is 'version' and so is every name that has been suggested so far. Suggestions welcome, if only to confirm how tricky naming this is.

Robert Newson
  • 4,631
  • 20
  • 18
  • I'm going to throw **variant** in as my suggestion – Jacob Groundwater Nov 25 '11 at 20:05
  • Variant seems unspecific. In my software I've used variant to indicate an alternative view of some data. What about something that more reveals the technical side of the dbms, like *write_order* or *save_number*? – mortb Oct 29 '12 at 12:46