[SERVER-29735] add support for $elemMatch-like semantics in restrictSearchWithMatch of $graphLookup Created: 20/Jun/17 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Aggregation Framework |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Jame Yang | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | usability | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Optimization
|
| Participants: |
| Description |
|
restrictSearchWithMatch of $graphLookup with array not work when search into array element. |
| Comments |
| Comment by Asya Kamsky [ 01/Jul/17 ] | |||||||||||||||||||||||
|
Absolutely agreed, as creating a new view is not always feasible, but I'm glad the workaround is helping you until a full solution can be implemented. | |||||||||||||||||||||||
| Comment by Jame Yang [ 30/Jun/17 ] | |||||||||||||||||||||||
|
@asya, your solution of createView is very good, now running in the project with no problem. Thank you! However, it's just a workaround, using restrictSearchWithMatchCondition is the best choice. | |||||||||||||||||||||||
| Comment by Asya Kamsky [ 27/Jun/17 ] | |||||||||||||||||||||||
|
In current version, there is a workaround possible using "views" - a view is defined via a pipeline and you can create a view that only contains valid relation entries. Create view with only valid:true entries:
Now you would omit the restrictWithMatch condition and just do:
| |||||||||||||||||||||||
| Comment by David Storch [ 26/Jun/17 ] | |||||||||||||||||||||||
|
Thanks for the additional info, futurist! I don't think the system currently supports this behavior. I am going to convert this report into a feature request and send it to the Query Team for triage. | |||||||||||||||||||||||
| Comment by Jame Yang [ 24/Jun/17 ] | |||||||||||||||||||||||
|
Hi, David, Thanks for the answer.
Is just what I'm thinking of the $graphLookup working, since the reasonable steps of above example: when the document {id: 2} passes through the $graphLookup stage 1. $graphLookup will perform find({'to.id': 2}), which will find below document:
2. then after that, restrictSearchWithMatchCondition should take into account of the graph connection, since array element {id:4, valid: true} is not connected in connectToField, it should not appear in any further condition match. In other words, restrictSearchWithMatchCondition should only be restrict match from the already connected array elements only, not a simple find again query: find({"to.id": 2, "to.valid": true}), which will extend the connection, not a restrict. Below
is the right behavior, I believe. | |||||||||||||||||||||||
| Comment by David Storch [ 23/Jun/17 ] | |||||||||||||||||||||||
|
Hi futurist, Thanks for this issue report. From what I can tell, this query is working as designed. Let's just take the example of what happens when the document {id: 2} passes through the $graphLookup stage. First, $graphLookup will evaluate the startsWith value. In this case, startsWith evaluates to 2. This value is used to seed the breadth-first search. The system will look for documents in the from collection for documents whose connectToField has a value of 2, and will filter out documents based on the restrictSearchWithMatchCondition. That is, the system will internally issue the following query against the ooo collection:
Since this document matches, it appears in the as field ("relation"). The behavior does not change when you remove the restrictSearchWithMatch condition because the internally issued query still matches the same document:
If I understand correctly, you wish the internally issued query to apply $elemMatch-like semantics:
In other words, an id of 2 and value: true must appear in the same array element in order for the document to match. This functionality is currently not supported by $graphLookup. I am going to move this ticket into "waiting for user info" state; please confirm whether or not this is the functionality you need so that I can convert this ticket into the appropriate feature request. Also, let me know if you have any questions about my explanation. Best, |