Strange error message - couchdb

Question

I have defined the following view:
{ "_id":"_design/test",
"language":"javascript",
"views":
{ "test":
{ "map": "function(doc) { for (var k in doc.data) emit(doc.data[k],null);}",
"options": {"collation":"raw"}
}
}
}
When querying the view without any parameters, I get the expected result (sorted as "AB...ab" instead of "aAbB" because I specified a raw collation):
http://localhost:5985/test/_design/test/_view/test
{"total_rows":13,"offset":0,"rows":[
{"id":"-","key":"A","value":null},
{"id":"-","key":"B","value":null},
{"id":"-","key":"C","value":null},
{"id":"-","key":"D","value":null},
{"id":"-","key":"E","value":null},
{"id":"-","key":"F","value":null},
{"id":"-","key":"a","value":null},
{"id":"-","key":"b","value":null},
{"id":"-","key":"c","value":null},
{"id":"-","key":"d","value":null},
{"id":"-","key":"e","value":null},
{"id":"-","key":"f","value":null},
{"id":"-","key":"g","value":null}
]}
I then use startkey and endkey to ask for the range between B and a, and I expect to receive keys BCDEFa, but instead I receive the following error message:
http://localhost:5985/test/_design/test/_view/test?startkey=%22B%22&endkey=%22a%22
{ "error": "query_parse_error",
"reason": "No rows can match your key range, reverse your start_key and
end_key or set descending=true"
}
Why does it say that no rows can match the key range, when rows B,C,D,E,F and a will match ?
EDIT: I have a single document (revision and ID omitted):
{ "_id": "-",
"_rev": "-",
"data": [ "A", "B", "C", "D", "E", "F", "a", "b", "c", "d", "e", "f", "g" ]
}

Answer 1

I can confirm that I experience the same behaviour in version 1.1 on Ubuntu 10.04.
To elaborate:
curl http://localhost:5984/test/_design/test/_view/view?startkey=%22B%22\&endkey=%22a%22
returns the error
{"error":"query_parse_error","reason":"No rows can match your key range, reverse your start_key and end_key or set descending=true"}
while
curl http://localhost:5984/test/_design/test/_view/view?startkey=%22B%22\&endkey=%22D%22
gives
{"total_rows":12,"offset":1,"rows":[
{"id":"stuff","key":"B","value":null},
{"id":"stuff","key":"C","value":null},
{"id":"stuff","key":"D","value":null}
]}
So quoting issues don't look to be the problem.
I am using a single document:
{
"_id": "stuff",
"_rev": "2-0507028fcab427a1b28ed6b3d4a6c05e",
"data": [
"A",
"B",
"C",
"D",
"E",
"F",
"a",
"b",
"c",
"d",
"e",
"f"
]
}

Answer 2

I have found this tip on http://guide.couchdb.org/draft/views.html (paragraph Reversed Results).
hoping that could help you.
Reversed ResultsTo retrieve view results in reverse order, use the descending=true query parameter. If you are using a startkey parameter, you will find that CouchDB returns different rows or no rows at all. What’s up with that?
It’s pretty easy to understand when you see how view query options work under the hood. A view is stored in a tree structure for fast lookups. Whenever you query a view, this is how CouchDB operates:
Starts reading at the top, or at the position that startkey specifies, if present.
Returns one row at a time until the end or until it hits endkey, if present.
If you specify descending=true, the reading direction is reversed, not the sort order of the rows in the view. In addition, the same two-step procedure is followed.
Say you have a view result that looks like this:
KeyValue
0"foo"
1"bar"
2"baz"
Here are potential query options: ?startkey=1&descending=true. What will CouchDB do? See #1 above: it jumps to startkey, which is the row with the key 1, and starts reading backward until it hits the end of the view. So the particular result would be:
KeyValue
1"bar"
0"foo"
This is very likely not what you want. To get the rows with the indexes 1 and 2 in reverse order, you need to switch the startkey to endkey: endkey=1&descending=true:
KeyValue
2"baz"
1"bar"
Now that looks a lot better. CouchDB started reading at the bottom of the view and went backward until it hit endkey.

Answer 3

After looking again through wads of documentation and asking around, it seems that this behavior is unintended. I have submitted a JIRA bug for this. I currently have no general-purpose workaround to suggest, though I have been able to work around the problem in my specific situation.