Christopher Lenz: CouchDB views are basically highly efficient on-disk dictionaries that map keys to values, where the key is automatically indexed and can be used to filter and/or sort the results you get back from your views. When you “invoke” a view, you can say that you’re only interested in a subset of the view rows by specifying a
?key=foo query string parameter. Or you can specify
?endkey=bar query string parameters to fetch rows over a range of keys. It’s also important to note that keys are always used for collating (i.e. sorting) the rows.
Jacob Kaplan-Moss: The wins go deeper than APIs, though. Think about what it would take to add load-balancing to CouchDB. I’ll give you a hint: perlbal. Or what about adding a transparent caching layer? Try Squid. HTTP is the lingua franca of our age; if you speak HTTP, it opens up all sorts of doors. There’s something almost subversive about CouchDB; it’s completely language-, platform-, and OS-agnostic.
Dan Sickles: I’ve always said that you don’t need an ORM if there’s no R.
To this, I’ll add that if CouchDB could efficiently compute an ETag† for
endkey type queries by only accessing the index, this could be a big win. Most shared-nothing applications would simply become a dispatcher, a few views, and a few templates. The most complicating thing your application need worry about would be when you need to assemble a page using input from multiple views.
† yes, indeed, I am a broken record on this subject — get over it