[SERVER-6613] using $elemMatch projection with $all gives unexpected results Created: 26/Jul/12 Updated: 08/Dec/15 Resolved: 08/Dec/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 2.2.0-rc0, 2.6.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jeffrey Yemin | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
When using $all, it results in x not appearing in the results
May be better to uassert instead. |
| Comments |
| Comment by David Storch [ 08/Dec/15 ] | |
|
This looks like it is "Works as Designed" to me. The $elemMatch projection
should be read as "where x is an array, include only the first array element matching <something>". Nothing gets project because none of the array elements (1, 2, 3, 4, or 5) match the predicate { $all: [1, 2, 3] } }. | |
| Comment by Thomas Rueckstiess [ 29/Jul/14 ] | |
|
This is still reproducible with above script in 2.6.3. | |
| Comment by Ben Becker [ 26/Jul/12 ] | |
|
Yes, we should definitely uassert if $all is specified as a parameter to $elemMatch. |