paultranvan opened a new issue, #4511:
URL: https://github.com/apache/couchdb/issues/4511
## Description
When a mango query includes a `use_index` option and the specified index
does not exist, CouchDB might fallback on an existing index, which can cause
unexpected behavior.
## Steps to Reproduce
Consider the following mango query:
```
{
"selector": {
"worker": "service",
"$or": [
{
"state": "queued"
},
{
"state": "running"
}
]
},
"sort": [
{
"worker": "asc"
}
],
"use_index": "_design/by-worker"
}
```
Now suppose the `_design/by-worker` index does not exist, but there is an
existing one on the same fields:
```
{
"index": {
"fields": ["worker", "state"]
},
"ddoc": "_design/by-worker-and-state",
"type" : "json"
}
```
The `_design/by-worker-and-state` index will actually be used. However, this
can be problematic if the database is quite huge: the `$or` will be evaluated
in-memory, which could result in timeouts as the whole database will be scanned.
In our client logic, we first run the mango query and expect an error, if
the index does not exist. Then, we create the index, and run the query again.
This avoids to check if the index exists for every mango query, as it will be
the case most of the time.
See the logic
[here](https://github.com/cozy/cozy-client/blob/master/packages/cozy-stack-client/src/DocumentCollection.js#L279-L291).
In our example, if the index does not exist, we would create one with a
partial filter:
```
{
"index": {
"fields": ["worker"],
"partial_filter_selector": {
"$or": [
{
"state": "queued"
},
{
"state": "running"
}
]
}
},
"ddoc": "_design/by-worker-and-partial-state",
"type" : "json"
}
```
This avoids to evaluate the `$or` at query time, and potential timeouts. But
because of the existing index being used, we never have the opportunity to
create the actual and efficient index.
## Expected Behaviour
We expect any mango query including a `use_index` to immediately fails if
the index does not exist. This seems reasonable to force the use of a
particular index without any fallback, as it might lead to sub-optimal queries.
## Your Environment
* CouchDB version used: 2.3.1
* Browser name and version: Not relevant
* Operating system and version: Not relevant
## Additional Context
This issue can be convoluted by specifying a sort on fields that are used on
the existing index, but this is not really a solution for us.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]