[
https://issues.apache.org/jira/browse/COUCHDB-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080714#comment-13080714
]
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: https://issues.apache.org/jira/browse/COUCHDB-1228
> 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: http://www.atlassian.com/software/jira
