On 29/12/2008, at 1:48 PM, Chris Anderson wrote:
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
endkey.
I use precise endkeys with descending=true when paging backwards, or
capturing the end of a range when the the user deletes all elements on
the last page of a view and I need to refresh that page (which
involves finding the final page of a paged view). I don't use page
offsets at all for scalability, which is why being able to swap
endkey(_docid)/startkey(_docid) is important.
So given that descending=true swaps the start/end parameters, I think
the inclusiveness would have to swap as well.
And it probably wouldn't eliminate the ["mystring", {}] / "mystring
\uFFF8" techniques, because the problem of generating a precise
succ(key) is more complicated, for strings at least, especially once
CouchDB handles Unicode collation properly.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Human beings, who are almost unique in having the ability to learn
from the experience of others, are also remarkable for their apparent
disinclination to do so.
-- Douglas Adams
