CouchDB Weekly News, October 02, 2014

Major Discussions

Are attachments duplicated for each revision as well? (see thread)

Question: Given that attachments are seemingly stored as key/value pairs within a document, does that mean that each revision of a document contains the
attachments as well?  Or are they stored independently?

Answers:

  • The attachment will be stored once and each revision will retain a reference to that attachment (including when it was added, called revpos, so replication should be efficient too). Compaction will copy the attachments over and should retain a single copy for each unique attachment.
  • Attachments are identified by name and can be replaced without mutating old references to documents with attachments of the same name. If users pass the _attachments section and leave out stubs for any existing attachments, that is interpreted as a delete.
  • This means that users have a version of each attachment at a given revpos. So this means that they can replace or delete the attachment, but old revisions will reference them until they are culled by compaction.
  • If users have conflicting revisions they will both be able to keep different attachments under the same name. So if there are conflicts, users will possibly have more attachments. It’s possible to play around with this more by using the atts_since=N query parameter, but one should keep in mind that content is not currently deduplicated between different documents so that is where the application can do some work to ensure that only one of anything is stored by using a digest like SHA1 or similar as the document id. This artificially restricts one attachment per doc but I find things work a bit better when users avoid having huge numbers of attachments to manage per document.

How to store the delta between doc revisions? (see thread)

Question: A user asked about the best way to store a history of changes for a document. Originally, they were thinking what makes the most sense is to use the update function of CouchDB but not entirely sure if they can. Is there some way to use the update function and modify/create a second document in
the process? They now want to create a “history_log” document, where they can just store the delta between documents (as a patch, for example).

Answers:

  • Storing patches is good until users are sure that no single patch will
    get suddenly deleted. Otherwise they could easily find all their history
    broken.
  • Storing full document copies per revision is the more solid solution for such case: users can easily skip or lose one or several revisions and be fine, but it also consumes much more disk space.
  • It’s possible to create the validate_doc_update function which will verify that every new stored item contains some specific data (like previous document version to which validate_doc_update also has access), but all this leads to storing history logs inside a single document. If users want to track it separately, changes feed and update_notification_handler can be used, but then race conditions could happen (especially if compaction gets triggered), so there will be always a chance miss some revision.

Releases in the CouchDB Universe

  • The CouchDB Replication Protocol is now renewed and ready for use. It was designed to describe every single protocol bit to let everyone
    create their own replicator implementation without needing to read the source code or similar to understand how it works in every certain case. Ideally, you should open only this single page and be able to
    implement your CouchDB compatible replicable solution with zero
    experience with the CouchDB API. If you failed or found some bits missing – feel free to send PR with fixes!

Opinions and other News in the CouchDB Universe

Use Cases, Questions and Answers

No public answer yet:

For more new questions and answers about CouchDB, see these search results.

Get involved!

If you want to get into working on CouchDB:

  • We have an infinite number of open contributor positions on CouchDB. Submit a pull request and join the project!
  • Can you help with Web Design, Development or UX for our Admin Console? No Erlang skills required! – Get in touch with us.
  • Do you want to help moving the CouchDB docs translation forward? We’d love to have you in our L10n team! See our current status and languages we’d like to provide CouchDB docs in on this page. If you’d like to help, don’t hesitate to contact the L10n mailing list on l10n@couchdb.apache.org or ping Andy Wenk (awenkhh on IRC).

We’d be happy to have you!

Events

Time to relax!

  • “Our early design was the problem. It was designed for right-handed users, but phones are usually rotated 180 degrees when held in left hands. Without realizing it, we’d created an app that worked best for our almost exclusively right-handed developer team.”You don’t know what you don’t know: how our unconscious minds undermine the workplace
  • “I am not anti-criticism of the applications we use, but I am suggesting we be mindful of how this discussion takes place. People make these things we use every day. Show them the same love and empathy you would want on launch day.” – To end all rage tweets

… and also in the news

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s