Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Sat, 6 Aug 2011 10:57:27 +0000 (UTC)
From: "Bob Dionne (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: 
 <912237583.13785.1312628247154.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <566089212.7229.1311155103705.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (COUCHDB-1228) Key range error apparently
 ignores view collation
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/COUCHDB-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080394#comment-13080394 ] 

Bob Dionne commented on COUCHDB-1228:
-------------------------------------

Looks like the problem is in couch_httpd_view:warn_on_empty_key_range, it makes use of couch_view:less_json as the default instead of taking the collation option into account.

Shouldn't be too hard to fix in the view case but I'm not sure how to handle the case of _all_docs

> 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
>
>
> 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