Obviously, you have to make sure that you enabled native Erlang views. Make sure to read on how to enabled your Erlang views on the CouchDB wiki

Once you are done, you can go into Futon and you should see “Erlang” in the list of available view languages:

Futon CouchDB

Ok, let’s get into technicalities and the interesting stuff now, imagine you have a bunch of documents in your database and you want to get a list of documents that have a “name” and a “value” field. In javascript the view would be quite simple, it would look somewhat like:

Which is perfectly fine, however in Erlang it’s a bit different, if you want to use a field, you have to make sure it’s there.

For the purpose of this post and trying to keep it short, I’ve made a rather simple view with 2 functions (fun()). 1 to validate the fields are present in the document and 1 to emit what we need.

or the compacted version:

Go to Futon’s temp view editor, select language Erlang, paste the previous code, click on Save and save your view.

Go to Futon’s temp view editor, select language Javascript, paste the javascript code above, click on Save and save your view.

They should both return the same output and you now have your first Erlang view working

Note that if you want to have a reduce function, this map function has a major flaw. I’ll point it out with an explanation in the second post regarding CouchDB Map/Reduce functions

Special thanks to Adam Kocoloski from Cloudant for the peer review and compact version of the Erlang map function and Jan Lehnardt from Couchio for the general help with Erlang views

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.