[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:
Depends
is depended on by SERVER-1264 $elemMatch on subArray Closed
Related
is related to SERVER-2238 New projection operator $elemMatch Closed
Operating System: ALL
Participants:

 Description   

When using $all, it results in x not appearing in the results

for ( i = 0; i < 100; i++ ) {
    t.insert({ group: 1, x: [ 1, 2, 3, 4, 5 ] });
}
> t.find( { group:1 }, { _id : 0, x: { $elemMatch: { $all:[1, 2, 3] } } } ).limit(1)
{ }

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

{x: {$elemMatch: <something>}}

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.

Generated at Thu Feb 08 03:12:12 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.