Nested fields. #2986
-
Hi, i have a problem with the index in nested fields.
I want to query the courses with the title "javascript-profesional" using this index:
But CouchDB responds with this:
With other query:
CouchDB responds with:
But if i query with a small modification in the selector
|
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 3 replies
-
Your index only has name and age available. The filter on courses looks like it might be throwing away all the records, and indexing nothing - if so, then querying that index for all records give you zero results. I haven't found a way to query array-content effectively with a Mango index. I have used a map-reduce index to do cases like your search-by-single-course scenario. Or, as I understand, a full-text-index may be useful for that. |
Beta Was this translation helpful? Give feedback.
-
It looks like it's doing a full index scan (over the docs that passed the defined partial_filter_selector, in name+age order) and warning that it checked many more docs than it returned (thus costing more I/O at the database, and some CPU for checking your conditions on every student who had one of the filtered courses). While technically it is "using" an index during query resolution, that doesn't mean you have gotten efficiency from it; as your db grows, you'd likely experience query slowdowns and rising CPU+I/O costs. If the partial_filter_selector is eliminating a large number of docs from index-inclusion, that would otherwise have caused your query to be MUCH MORE expensive, then it may be giving you good-enough leverage against the total volume of docs in your db, and the warning (and I/O+CPU consumption) may be of secondary importance. That's your call based on expected volume & usage patterns. Looking at your definitions again, I'd look at using a map/reduce index (instead of a mango index+query) on course-title (or id), then query the intended course value directly in that index - thus resolving your query with a high-efficiency index-range-scan even if your data volume grows a lot. I'd still like to see Mango be able to resolve a query like this using an index-range-scan (perhaps by supporting |
Beta Was this translation helpful? Give feedback.
-
You're right, one sometimes has to piece together bits from different places to arrive at working results for a specific case. Here's an example of a map & reduce for indexing attributes
Querying it based on some
See https://docs.couchdb.org/en/3.1.0/api/ddoc/views.html for more about querying. |
Beta Was this translation helpful? Give feedback.
-
When you use a |
Beta Was this translation helpful? Give feedback.
You're right, one sometimes has to piece together bits from different places to arrive at working results for a specific case.
Here's an example of a map & reduce for indexing attributes
{id, name}
in an array ofTHINGS
in some documents. These attributes need to be included in a design-doc view.Querying it based on some
thingId
could use view-querying options such as those shown here, with the unicode character indicating a hard end to the key range.