couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Joseph Davis (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1228) Key range error apparently ignores view collation
Date Mon, 08 Aug 2011 01:35:27 GMT


Paul Joseph Davis commented on COUCHDB-1228:

The unintuitive part here is the optimizations we make when map functions are byte identical.
Ie, if you have the same map function and a number of different reduce functions, then we
only write one btree to disk for that map function. Its basically a short comming in how we
define map/reduce function pairs.

But the bottom line is that even if you have say three pairs of m/r functions, but the m function
is identical in all three, then all three are represented as a single #view{} record. Its
basically {MapFun, [{ReduceName, ReduceFun} | RestRedFuns], OtherMetaStuff}.

The {reduce, N, Lang, View} tuple is just wrapped around a #view{} record to indicate which
reduce function is being referred to. Of course this could've been defined as -record(reduce,
{nth, language, view}). but wasn't for some reason long ago. Bottom line is that all of those
reduce functions and the underlying map function have an identical sort ordering, so all you're
doing is extracting the view to get at that info.

(Side note, when I said byte-identical map function, they also have to have identical view
options values as well)

> Key range error apparently ignores view collation
> -------------------------------------------------
>                 Key: COUCHDB-1228
>                 URL:
>             Project: CouchDB
>          Issue Type: Bug
>          Components: HTTP Interface
>    Affects Versions: 1.1
>         Environment: Debian
>            Reporter: Victor Nicollet
>             Fix For: 1.1.1
>         Attachments: 0001-Whitespace-and-comment-clarification.patch, 0002-Unit-tests-for-proper-key-range-support-during-raw-c.patch,
0003-Support-correct-key-range-semantics-for-raw-collatio.patch, trunk.0001-Whitespace-and-comment-clarification.patch,
trunk.0002-Unit-tests-for-proper-key-range-support-during-raw-c.patch, trunk.0003-Support-correct-key-range-semantics-for-raw-collatio.patch
> I have created a view (no reduce function) with "options":{"collation":"raw"} and emit
documents with keys "A", "C" and "b". Running a request on that view with no parameters, I
get as expected all three documents in order "A", "C" and "b" as required by the raw collation
(instead of "A", "b", "C" for the default ICU collation).
> However, when I run a request with start key "B" and end key "a", I expect the "C" document
to be returned alone (as "B" < "C" < "a") but couchDB responds:
> { "error": "query_parse_error", "reason": "No rows can match your key range, reverse
your start_key and end_key or set descending=true" }
> This error would make sense if I had been using the default ICU collation, where "B"
> "a", but with the raw collation the reverse ("B" > "a") is true. It looks as if the
key order warning does not take the view collation into account.

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message