There are many decisions involved when using new technologies and new products. Many people will often go for open source software because it’s free and you can modify the code. To me being “an open source” project involves a whole lot more than simply having an opened code base that you can modify and use for free, but it also involves a large amount of factors as such as technical documentation, user examples, tools for a software, the community based around a project and the likes of actual response time from developers.
This article is a major Kudos to the CouchDB developers. In particular I would like to thank Jan Lehnardt, Paul J. Davis and Robert Newson from the CouchDB fame. Let me explain why…
For all the skeptics (As I was and still am with some concepts) I have to admit that jumping both feet into CouchDB is scary, especially coming from an RDBMS-core background. I think in joins, I see relations, I’m a normalized database person. Coming with the idea that de-normalization can actually be ok if it’s done correctly was hell for me.
So the first things we did when using Couch was creating databases, until then, in my head, using “many” databases was always a big no-no simply because it was making management of connections and everything hectic. However, with CouchDB it’s a bit different and that’s a concept that Jan helped me understand and it can indeed be correctly done if planned thoroughly.
After finding myself in many dead-ends after starting CouchDB, the previously mentioned helpers were always there even for the simplest, most ridiculous questions I could have answered myself by re-reading my questions.
Imagine the following scenario where you have a list of documents that have two fields. “time” and “type“. the “type” field can be either “love” or “hate” and and “time” field is a unix timestamp (php -r ‘echo time() . PHP_EOL;’).
We need to create views in order to retrieve the data. The first scenario involves counting the amount of types. So how many documents with type “love” and how many documents (entries) with the field type with value “hate“.
You will mostly likely have to do a reduce function as well as your view. So using futon you can create your simple view that’ll look like such:
View:
1 2 3 4 5 | function(doc) { if(doc.type) { emit(doc.type, 1); } } |
and your reduce function to look somewhat like:
1 2 3 | function(key, values) { return sum(values); } |
Now Save this as design document “example” and view name “countdocbytype“. (See image below)
This is all very nice but what does that give you the ability of doing? Remember that “WHERE type = ‘get’” in SQL? Well now that you saved that view you can effectively search on the key you are returning in your emit() function. In this case you are returning the doc.type thus “hate” or “love” which means that if you want to get a count of type “hate” you will invoke your view as such:
http://localhost:5984/databasename/_design/example/_view/countdocbytype?group=true&key=”hate”
Remember that this is all JSON lovin’ so the key you are passing has to be JSON encoded (So key=”hate“ instead of key=hate). This view (Query for SQL people) will return a count of entries/documents with the field “type” that has the value “hate”
For the second example let’s introduce a new field in our documents, let’s name the field “phone” and it’ll be “iphone” and “android“. Update your documents and put as many “iphone” and “androids” as you want. The next example is going to be finding how many people hate iphones (This implies searching for a count of field “phone” with value “iphone” and field “type” with value “hate“).
Documents updated? Good.
Now let’s make our view:
1 2 3 4 5 6 | function(doc) { if (doc.phone && doc.type) { var keys = [doc.phone, doc.type]; emit(keys, 1); } } |
and the reduce to return a sum of the values:
1 2 3 | function(key, values) { return sum(values); } |
In Futon it would look somewhat like:
With the results looking like:
So now again save it as design “example” and view name “countdocbyphoneandtype” and now you can invoke the following URL.
http://localhost:5984/databasename/_design/example/_view/countdocbyphoneandtype?group=true&key=["iphone", "hate"]
As you can see, we are passing an array in the “key” field with the values “iphone” and “hate“. This retrieves all the “phone” fields with value “iphone” and then from that resultset all the field “type” with value “hate“. It gives us the following type of output:
1 2 3 4 5 6 | { "rows":[{ "key":["iphone","hate"], "value":2 }] } |
You now have a query that searches for “two” fields in your document.
I strongly suggest to read the wiki and anything related to views if you are remotely interested in using CouchDB as they are going to be your main source of nightmares and happiness. The latter example, was nicely explained to me on the IRC channel even though it was plain black and white on the wiki… Apparently I just couldn’t see it clearly enough. There are loads of little things with the views that require user experience instead of wiki reading and the people on the IRC channel have used CouchDB, they’ll get you by 
Moving on, on top of many exciting upcoming features (as such as continuous replication, bulk inserts, etc.) the project has online documentation, online books for people to read for free (Even though I strongly recommend buying the book), a vibrant IRC channel with the nicest helpers from extensive users to software developers/creators to book authors.
When in need of direction, if you really can’t find it online or don’t understand how it’s explained, you can hop on the IRC channel and get your well formulated questions answered at all times. With a thorough patch review process and code quality insurance,in my opinion, it makes CouchDB a very solid open source project that should be respected and should serve as example for any new software that wants to make it into the open source world.
