couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick North <>
Subject Re: question about "complex" range queries
Date Wed, 02 Apr 2014 07:31:24 GMT
It doesn't work quite like this. There is a single order across all
possible keys, including both simple and complex keys, as described
In the case of keys that are lists, the two lists are compared element by
element and the sort order is the sort order of the first unequal elements.

In your example, if a key has its first element between a1 and a2 (and a1
and a2 are different), then the second element will not be inspected at
all, so it does not matter whether it is between b1 and b2 or not. In fact
the second element will only be inspected if the first element is either a1
or a2.

This is usually the behaviour we want. For example, dates are often
represented as lists of [year, month, day]. Then you can pull out all the
documents in a date range by specifying start date and end date as startkey
and endkey. For example, if these are [2012, 4, 5] and [2014, 8, 3]
respectively, we want to include [2013, 3, 6] in the output even though its
second element does not lie between the second elements of the keys.


On 2 April 2014 03:56, Schroiff, Klaus <> wrote:

> Hi,
> Let's assume that I have the following view function:
> function(doc) { emit([a, b], whatever) } }
> In the query I'm running something like
> startkey=[a1, b1] & endkey=[a2,b2]
> Thus there're TWO explicit ranges here - a1->a2 and b1->b2.
> What is the expected result ?
> My understanding:
> The query is executed in two phases
> In the first phase, the index is filtered for qualifying results where the
> first key ranges from a1 to a2
> In the second phase, these filtered results are filtered once more
> according to the range of the second emitted key from b1 to b2.
> Thus essentially an "AND" operation.
> The filtering is performed using lexicographical rules.
> Is that correct ? The doc about complex keys is a bit slim.
> Thanks
> Klaus

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message