[SERVER-69377] Support $elemMatch in query analysis Created: 01/Sep/22 Updated: 05/Dec/22 |
|
| Status: | Open |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Davis Haupt (Inactive) | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Query Optimization
|
||||||||
| Participants: | |||||||||
| Description |
|
The children expressions of $elemMatch are parsed as top-level expressions, without the path prefix of the enclosing array. Therefore, when we recurse into the children expressions and try and look up the encryption metadata for the path, we get the metadata for the top-level schema rather than any schema information for the embedded document in the array field. This ticket should add a way to automatically prepend the path prefix of the array field to all requests for metadata to a given EncryptionSchemaTree. That way we could pass this "prefixed" schemaTree down to the recursive query analysis call to allow query analysis to access the proper encryption metadata. |
| Comments |
| Comment by Davis Haupt (Inactive) [ 01/Sep/22 ] |
|
A simple solution would be to pass in *schemaTree.getNode(prefix) to the recursive call. That way all further recursion would treat the subquery like it is operating on a toplevel document, matching the parsing behavior. |