12

I'm currently working on a wiki-esque application using CouchDB and am trying to implement a document versioning scheme. The way I see it there are two ways of doing this:

  1. Store each version as a separate document
  2. Store older versions as attachments to a single document.

Right now, I've got a form of #1 working. When a user edits a document and saves it, the back-end first copies the previous revision to a new document and then saves the new version. Each document has a 'history' array that contains data on each version (the document _id of the old version, a timestamp, the editor, etc.).

Since this history array could get pretty lengthy for a frequently updated document, I have a view that fetches a document sans history during a normal read (and another view for fetching the history).

My question is this: I feel uneasy about my current approach and have been thinking about changing to the 'attachment' method. But I'm not sure. I'm hoping someone who knows CouchDB better than I (I've only been at this for a couple weeks -- and this is my first project using CouchDB... and NoSQL) can tell me what the pros and cons are of each approach. Or is there perhaps some other versioning scheme that I'm overlooking?

migrated from programmers.stackexchange.com Oct 11 '14 at 7:19

This question came from our site for professionals, academics, and students working within the systems development life cycle.

  • 2
    While I can't speak to the performance impact at all, the system you are using is "spiritually" in line with CouchDB. Storing previous versions as a response hierarchy is idiomatic, as it is in the "spiritual ancestor" of CouchDB, the Lotus Notes document database (NSF) (Damien Katz worked deeply on the one before developing the other, keeping and improving the best of it while tossing the cruft and backward/bugward compatibility requirements, so many of the more basic structural questions will have answers in Notes.) – Stan Rogers Oct 4 '14 at 14:58
2

Storing only changes will be a good idea, because storing older documents as separate documents or attachments to the final revision of database will create an overhead to database server.

When ever you change a key value in your document, add a new key named _h_i_s_<key_name>. In the newly created( or created during last update), append objects like below after every edit/update:-

{
key_name: "Hello",
_h_i_s_key_name:{time_of_update:value_of_key_name_before_update},
....
}

or

    {
    key_name: "Hello",
    _h_i_s_key_name:[{time:time_of_update,value:value_of_key_name_before_update}, {time:time_of_last_update,value:value_of_key_name_before_last_update}],
    ....
    }

This approach will save a lot of disk space and replication bandwidth in long run.

0

Without any knowledge of CouchDB. Storing every version though may only differs marginal from its predecessor is a waste of storage. I'd recommend storing changes only.

You might want to take a look here or search for data versioning.

  • This answer fails to say which of option 1 (separate documents) or 2 (as part of document) is better. – binki Jan 19 '17 at 16:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.