Mutual exclusive: key, keys, start_key and end_key

[jiahuili430]

Overview

1. key behaves as if we set startkey=$key&endkey=$key. There is some confusion when we use them together. We should raise a 400 bad request when using key, keys, startkey and endkey together.

- Previous behavior:
When setting endkey to a, it will return doc a. But if we add key=c, it will rewrite startkey and endkey to c, then only doc c will be returned.

$ curl -XPUT $DB/db
$ curl -XPOST $DB/db/_bulk_docs -H 'Content-Type: application/json' -d '{"docs": [{"_id": "a"},{"_id": "b"},{"_id": "c"}]}'

$ curl $DB/db/_all_docs'?endkey="a"'
{"total_rows": 3, "offset": 0, "rows": [
    {"id": "a",
      "key": "a",
      "value": {"rev": "1-967a00dff5e02add41819138abb3284d"}
}]}

$ curl $DB/db/_all_docs'?endkey="a"&key="c"'
{"total_rows": 3, "offset": 2, "rows": [
    {"id": "c",
      "key": "c",
      "value": {"rev": "1-967a00dff5e02add41819138abb3284d"}
}]}

- After the change:

$ curl $DB/db/_all_docs'?endkey="b"&key="c"'
$ curl $DB/db/_all_docs'?keys=\["c"\]&startkey="b"'
$ curl $DB/db/_all_docs'?key="b"&keys=\["b"\]'
{
  "error": "query_parse_error",
  "reason": "`key`, `keys`, `start_key`, and `end_key` are incompatible"
}

---

2. Add a flag enable_key_exclusivity to enable/disable mutual exclusivity for keys

---

3. Execute a view with reduce function with key and single element keys, the response is different. We should treat one element keys the same as key and respond with the same result. If keys has multiple elements, it should behave as before.

$ curl -XDELETE $DB/db && curl -XPUT $DB/db
$ curl -XPOST $DB/db/_bulk_docs -H 'Content-Type: application/json' -d \
'{"docs": [{"key": "meatballs", "value": 1}, {"key": "spaghetti", "value": 2}, {"key": "tomato sauce", "value": 3}]}'
$ curl -XPOST $DB/db -H 'Content-Type: application/json' -d \
'{"_id": "_design/ddoc",
    "views": {
        "map_reduce": {
            "map": "function(doc) { emit(doc.key, doc.value) }",
            "reduce": "_sum"
}}}'

- Previous behavior:

$ curl $DB/db/_design/ddoc/_view/map_reduce'?key="meatballs"'
{"rows":[{"key":null,"value":1}]}

$ curl $DB/db/_design/ddoc/_view/map_reduce'?keys=\["meatballs"\]'
{
  "error": "query_parse_error",
  "reason": "Multi-key fetchs for reduce views must use `group=true`"
}

$ curl $DB/db/_design/ddoc/_view/map_reduce'?keys=\["meatballs"\]&group=true'
{"rows":[{"key":"meatballs","value":1}]}

$ curl $DB/db/_design/ddoc/_view/map_reduce'?keys=\["meatballs","spaghetti"\]'
{
  "error": "query_parse_error",
  "reason": "Multi-key fetchs for reduce views must use `group=true`"
}

- After the change:

$ curl $DB/db/_design/ddoc/_view/map_reduce'?key="meatballs"'
{"rows":[{"key":null,"value":1}]}

$ curl $DB/db/_design/ddoc/_view/map_reduce'?keys=\["meatballs"\]'
{"rows":[{"key":null,"value":1}]}

$ curl $DB/db/_design/ddoc/_view/map_reduce'?keys=\["meatballs"\]&group=true'
{"rows":["key":"meatballs","value":1}]}

$ curl $DB/db/_design/ddoc/_view/map_reduce'?keys=\["meatballs","spaghetti"\]'
{
  "error": "query_parse_error",
  "reason": "Multi-key fetches for reduce views must use `group=true`"
}

Testing recommendations

make eunit apps=chttpd,couch_mrview

Related Issues or Pull Requests

Fix #3977, #2243

Checklist

• Code is written and works correctly
• Changes are covered by tests
• Any new configurable parameters are documented in rel/overlay/etc/default.ini
• Documentation changes were made in the src/docs folder
• Documentation changes were backported (separated PR) to affected branches

[rnewson]

I like the clarity of the new errors but do not think we should combine key and keys. in my opinion that should be a 400 Bad Request.

[nickva]

There is a related issue about how key=onekey vs keys=[onekey] behaves with grouping #2243.

[nickva]

If we plan on toggling this on in 4.x we should add it to #4480 and make a note in docs about the new setting. Some users may want to enable it in 3.x already.

[nickva]

Looks good.

Great tests. Just had a few question and a suggestion to simplify the exclusivity check.

[rnewson]

I'm -0 on the behaviour change behind the exclusivity flag. I'd rather not have it, but I am not vetoing.

My reasoning is 1) It's disabled by default because 2) it will convert successful requests to failures 3) it will be a long time, if ever, before CouchDB will flip the default 4) It only fixes a subset of the validation issues in the _view endpoint.

I'd rather see us document the actual behaviour, silly as it is.

I'm fine with the part of the PR that treats a single item keys parameter as if you did key, since this transforms a current failure into success and (importantly) yielding the correct answer.

I've made a few specific comments on the diff.

[rnewson]

Key would be a better name for Val1 here.

[jiahuili430]

Thanks for your comments, I tried to rewrite this PR here #4494
Changed [Val1] to [SingleKeys] because Key is already used.

[rnewson]

Key would be a better name for Val2 here. I'd also inline the ?JSON_DECODE so we don't need a Val1

[jiahuili430]

Close this PR as #4494 has been merged.