[SERVER-59757] Evaluate supporting queries with match expressions on empty field names in SBE Created: 02/Sep/21 Updated: 13/Sep/22 Resolved: 12/Sep/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Andrii Dobroshynski (Inactive) | Assignee: | Drew Paroski |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Sprint: | QE 2022-09-19 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
There are queries in mongo that are valid which match on an empty field name (""). That means that documents such as these will be returned
Initially it was brought to our attention that SBE does not support this, and we found the reason was that we have to treat empty strings in a special way when generating nested traversals in SBE. The way recursive path traversal is implemented in SBE, if we wanted to start supporting a query like this, we would have to remove the special meaning an empty string has in $elemMatch (https://github.com/mongodb/mongo/blob/8179692b362d8237f201719946eb46bac6a5e961/src/mongo/db/matcher/expression_parser.cpp#L1276), because otherwise the SBE traversal code cannot tell if an empty string is coming from this parser code or if the empty string is actually something that we are trying to match against. The correct solution would be to refactor the code that makes an empty string have a special meaning and instead perhaps use boost::optional, but that is a massive change that is very invasive since every match expression expects a StringData and not an optional. |
| Comments |
| Comment by Githook User [ 13/Sep/22 ] |
|
Author: {'name': 'Drew Paroski', 'email': 'drew.paroski@mongodb.com', 'username': 'paroski'}Message: |
| Comment by Drew Paroski [ 12/Sep/22 ] |
|
david.storch@mongodb.com : Yes, I agree that makes sense. Closing as a duplicate of |
| Comment by David Storch [ 12/Sep/22 ] |
|
andrew.paroski@mongodb.com there were no commits against this ticket, right? In that case I think it might be clearer to resolve it as a duplicate of |