couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson" <>
Subject Re: API suggestions
Date Thu, 04 Dec 2008 18:04:33 GMT
On Thu, Dec 4, 2008 at 4:01 AM, Matt Goodall <> wrote:
> I'm aware that some are significant changes and would break language
> bindings but better now than post 1.0!

I'll try to answer without regard for breaking changes that would be the result.

> = Document Revisions =
> Identify document revision using a segment arg instead of query param, e.g.

I think the current ?rev=revstring approach is nice because in the
normal case, you'll be requesting the attachment without a rev
specified (eg you just want the latest). Standard query params are
also a little easier to deal with both in client libraries and in

> = Document Bits =
> = Reserved Names =
> Following on from "Document Bits", would it be sensible to reserve
> *all* path segments beginning with an underscore for CouchDB's use?

This is worth at least thinking about. Having the _attachments path
would open the door to an attachments index view, as well as
attachments with literal '/' in the name.

What do people think of the _attachment path as a way out of the %2F dilemma?

> = View API - start/end pairs =
> Would it make sense to combine the startXXX and endXXX pairs into a
> single range query param.

Doesn't make sense. 90% of the time I specify a startkey without an
endkey or vice versa.

> = View API - map/reduce/rereduce control =
>        "map" => reduce=false
>        "reduce" => reduce=true&group=true
>        "rereduce" => reduce=true&group=false

It's a little more complex than that, and built with future
extensibility in mind. For instance, you can have more than one named
reduce per map function, eventually, by using built-in erlang views.
eg: reduce=sum or reduce=row_count.

Chris Anderson

View raw message