couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson" <>
Subject Re: API suggestions
Date Mon, 29 Dec 2008 03:18:33 GMT
On Sun, Dec 28, 2008 at 6:12 AM,  <> wrote:
> I found no exact definition of startkey and endkey anywhere in the documentation. Testing
reveals that access on _all_docs and on views documents are retuned in the interval
> [startkey, endkey] = (startkey <= k <= endkey).

Just to argue for the status quo. Currently queries for ?key="mykey"
are converted to queries like ?startkey="mykey"&endkey="mykey".  Under
your proposed change, queries where the startkey and endkey are equal,
will return 0 rows. Changing the internals of exact key requests is
not insurmountable, but I think this does speak to the larger issue:

Inclusive keys are a little more intuitive (at least to me). If I
specify a key in my query, and it doesn't turn up in the results, but
I'm certain it should be in the view, this will be confusing,
especially at first. I'm a big believer in the principle of least

Otoh, I do understand the value to those who require mathematical
precision, especially for reduce queries, where application filtering
is not as feasible. And... endkey is usually used be people who are
trying to do something precise, so they are probably more likely to
pay attention to the docs and come to understand the exclusive
right-hand side. Most of the endkeys I've used would be compatible
with the proposed change. eg: I haven't actually been expecting the
key ["mystring",{}] to be in the result sets that come from using that

-- I started out arguing for the status quo, but the more I think
about it, the more it seems like this change would only effect power
users. Most users who notice this change would probably like it.

The change would reach pretty deeply into the Btree internals, so
there may be other reasons not to do it.

Chris Anderson

View raw message