Tutorial: CouchDB and Java with the ektorp library

It might be only my feeling that the amount of experiments and work done in the NoSQL space using dynamic languages (PHP, Python, Ruby, etc.) is bigger than what has been done so far using “big brothers” languages like C# or Java. That’s not to say that C# and Java developers do not like NoSQL, just that good resources are rare.

Recently the author of the Java CouchDB ektorp library has published ☞ an interesting tutorial on how to build a basic blog app^[1].

Here are my notes after going through the article:

• model classes must extend a library provided class (CouchDbDocument). Java being a single inheritance language, this might be an issue for complex class hierarchies, so I was wondering if an approach based on annotations (see JPA) would not work even better. Update: according to the author this is optional and there are also mechanisms available.
• “view” classes which provide through an annotation the CouchDB mapreduce based view definition.

It is also worth noting the comment around the model definition:

The relationship between BlogPost and Comment is modeled with a blogPostId field in Comment. In order to find the comments for a blog post a ‘by_blogPostId’ query has to be performed.

A perhaps more natural way would be let BlogPost keep its comments in a list. Although this is possible, this model would cause update congestion in the blog post document if many users post comments concurrently.

A better way is to keep each comment in its own document as no update conflict will occur.

We already talked a couple of times about how important is the role of data modeling while using a NoSQL storage. And even if CouchDB has ☞ a whole wiki page dedicated to modeling entity relationships and there are some articles covering schemaless data modeling, questions are still arising ☞ every ☞ day. The lesson to be learned from this is that: 1) you’ll need to carefully design your data model and 2) while you might be tempted to re-use an already known “pattern”, you’d better think twice about your application scenarios.