Almost all of of my recent work has been using NoSQL solutions, my favorite of which is Couchdb. Easily the best feature of Couch is the RESTful JSON API that it uses to provide data. Because you get your DB queries back to you directly as JavaScript objects, you don’t have to worry about application servers or middle tier systems for N-Tier development. This is HUGE and make the whole web development (and given that most mobile applications are actually web apps) must cleaner, faster, and more functional for the end user.
Couch does have a couple weaknesses. The one that has been giving me the most headaches is the lack of documentation for their parameters that the server can handle as part of the JSON View (map/reduce) phase. So here are a number that I have found useful over the last few months. I will update this list as I find more.
- key=abc The most commonly passed option to a given couchdb view. This provides a way to select a single unique (well, I guess probably unique) key for a given view. That said, view keys DON’T HAVE TO BE UNIQUE in couchdb. Meaning, that if more than one result returns with abc this will also return those multiple results.
- keys=[abc,123,ACC] A JSON encoded list of keys to use in a given map/reduce function. Basically the same as above but without the need to call multiple network queries.
- startkey=abc Used with endkey=abC to provide reange selection for a given view. startkey will accept (as valid input) anything that would be valid in a standard couchdb view key, even JSON objects. So think startkey=[a,]&endkey=[a,{}] to get a range of all keys=[a,somethingElse].
- endkey=abC Counterpart of startkey, see the above reference. One thing to note, it is generally better to specify another object and the end of a range if you want to inclusively select a range. So {} is a better end range value than ZZZZZZZZ is.
- limit=100 Select on the first N number of results. This parameter is particularly useful for paginated return results (like “showing 1-100 of 399.) Reduces network bandwidth for a given request. Because map/reduce functions are cached upon request, the response time for the server isn’t any faster, but there is less data to download.
- skip=100 Work with the above parameter limit to return a group result set. For example you can limit the return result to 100 documents starting from 101 going through 200 (think email counts in gmail) with the ?limit=100&skip=100.
- descending=true Reverses the return result order. Will also work with limit, skip, startkey, etc…
- group=true The default result for a given map/reduce function (which has been re-reduced) is a total, i.e. a single number. In my case this is seldom the result I am actually looking for so this command provides the bridge between the full re-reduce and what I is most commonly sought, the groups result. Your final results when this option have been passed it to return the reduced functions grouped by the map keys. Instead of a single row with {key:null, value:9999} you will get multiple rows with the key being the name of the map key i.e [{key:”bob”,value:”444″},{key:”tom”,value:555}]. If you created design documents and view them inside of Futon, group=true is the default. Which can be a little confusing when you actually try and make a JSON request and find you get a different result.
- group_level=2 An alternative to the above parameter is the group_level option which will actual group the resulting reduce by the number of levels specified IF you key is an array matching at least that many arguments. While the example above is for two levels the number can be as many array places as your key has. This become particularly helpful when working with years and dates. For a detailed example checkout this post. That said, group=true is the functional equivalent of group_level=exact.
- reduce=false Turn OFF the reduce function on a given map/reduce query. This is the default if not reduce is defined but you can override it on views that DO have a reduce function if you only want the results of the map.
- include_docs=true For map queries (that do not have a corresponding view) this option will include the original document in the final result set. This means the structure of your JSON rows object will be {_id, key, value, doc} instead of the normal {_id, key, value}. This will save you an additional JSON request if you are using the map query as a lookup for a particular database query.
