Translate partial filter selectors into indexed db indexes
- Dominant language
- JavaScript
- Stars
- 17.6k
- Forks
- 1.5k
- PR merge metrics
- No merged PRs in 30d
Description
### Issue
With the merging of #8523 mango indexes with `partial_filter_selector`s use the MapReduce Views on the indexeddb-adapter.
While this works, it reduces the performance, doesn't auto-update (by the browser), and has a different ordering.
This issue is to find a way to use native IndexedDB indexes for Mango Indexes with `partial_filter_selector`s.
There are two paths:
- Translate `partial_filter_selector`s into indexes.
- Or lobby for support of partial indexes for IndexedDB indexes to the W3C (SQL has them two, after all). This issue would then be use-case for it.
## Basic Translation
The easiest to translate are the [Implicit Operators](https://docs.couchdb.org/en/3.2.2-docs/api/database/find.html#implicit-operators) `$and` and `$eq` (in their implicit and explicit forms).
The following index:
```json
{
"index": {
"fields": ["title"],
"partial_filter_selector": {
"type": { "$eq": "story" }
}
}
}
```
could be translated into:
```json
{
"index": {
"fields": ["type", "title"]
}
}
```
And on querying the index PouchDB would then add the `"type": { "$eq": "story" }` to the query-selector, if it is missing.
The (In)equality operators (`$lt`, `$lte`, `$eq`, `$gte`, and `$gt`) could also be translated into the index.
So would the `partial_filter_selector` example for the PouchDB API docs translated to:
```json
{
"index": {
"fields": ["year", "title"]
}
}
```
and `year: { $gt: 2010 }` be added to the query-selector.
## `$or` Operator
Support for the `$or` Operator and alike are already more complicated, but doable.
They could be translated into an index just like `$and` would, but while fetching PouchDB would fetch each selector in the or-array and merge and sort the results.
## Rest
As a fall back for all selector which can't be translated into indexes, PouchDB should try the closest matching indexes. Query it, filter then the results. And continue this until the limit is reached.
This should(?) be faster then using the default `_id` index.
---
Is this feasible? Any ideas?
Contributor guide
Assessment
This issue has not been assessed yet.