[SERVER-55475] instock:{$slice:1} doesn't trigger the "inclusion" Created: 11/Mar/21 Updated: 27/Oct/23 Resolved: 26/May/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Question | Priority: | Minor - P4 |
| Reporter: | kuku super | Assignee: | Irina Yatsenko (Inactive) |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | APIv2, neweng, post-rc0 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Sprint: | Query Execution 2021-05-31 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
https://docs.mongodb.com/manual/tutorial/project-fields-from-query-results/
returned
it was expected to return
|
| Comments |
| Comment by Irina Yatsenko (Inactive) [ 26/May/21 ] | |
|
After reviewing $slice (projection) operator's behaviour we've concluded that it works as designed and that changing the behaviour cannot be done without the risk of breaking existing applications. To get inclusion semantics, please use $slice (aggregation) operator https://docs.mongodb.com/manual/reference/operator/aggregation/slice/. | |
| Comment by Ian Boros [ 21/May/21 ] | |
|
I agree with Asya. While these semantics are bizarre, I don't think changing them is worth the risk of breaking existing applications, especially given that this could just be worked-around by adding an inclusion on a non-existent dummy field?
When we re-wrote projection in 4.4 we were very careful to preserve these rules. | |
| Comment by Asya Kamsky [ 21/May/21 ] | |
|
Good question. Improving semantics is great but not at the cost of breaking currently working applications... | |
| Comment by Irina Yatsenko (Inactive) [ 21/May/21 ] | |
|
asya If we change $slice to imply inclusion, should then find({},{_id:0, x:0, y:{$slice:1}}) result in error or should it continue to work as it does currently? (it excludes the "x" field and modifies the "y" field) | |
| Comment by Kyle Suarez [ 31/Mar/21 ] | |
|
eric.sedor throwing this into Query Execution triage for team discussion. | |
| Comment by Eric Sedor [ 31/Mar/21 ] | |
|
It is documented for slice behavior in embedded documents that "If the $slice projection is part of an exclusion projection, the operation continues to return the other fields in the nested document." Question for QE: Is it or is it not a bug that slice also does not trigger the exclusion of other top level fields? | |
| Comment by Eric Sedor [ 31/Mar/21 ] | |
|
Thanks skydog.forstore@gmail.com, maxime.beugnet, I'm going to pass this on with a question about this behavior for the appropriate team. In the event we don't want to change this behavior, we'll want to improve the slice behavior documentation to describe this. Our docs describe how inclusion behavior works for embedded fields, but seems to be unclear on top-level fields. | |
| Comment by kuku super [ 11/Mar/21 ] | |
|
db.inventory.find( {"item":"postcard"}, {_id:0, instock:1, instock:{$slice:1}})
returned the same too |