[SERVER-1264] $elemMatch on subArray Created: 21/Jun/10  Updated: 26/Feb/19  Resolved: 12/Feb/18

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: 1.5.2
Fix Version/s: 2.6.0

Type: Bug Priority: Major - P3
Reporter: Andrea Fontana Assignee: Kelsey Schubert
Resolution: Done Votes: 12
Labels: query_triage, todo_in_code
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File server1264.js    
Issue Links:
Depends
depends on SERVER-6613 using $elemMatch projection with $all... Closed
is depended on by CSHARP-611 Support for Enumerable.Any in LINQ qu... Closed
Related
related to SERVER-7388 Implement all query operators using M... Closed
related to SERVER-6050 Consider allowing $elemMatch applied ... Closed
is related to SERVER-15727 two-dimension Array $elemMatch bug Closed
is related to SERVER-5506 Enhance SERVER-1264 style $elemMatch ... Backlog
Backwards Compatibility: Minor Change
Operating System: ALL
Participants:

 Description   

Here a test-case:

> db.test.insert({"field": [[100,300],[100, 110]]}) 
> db.test.findOne() 
{ 
        "_id" : ObjectId("4c1f229882c620b16f0d3fbd"), 
        "field" : [ 
                [ 
                        100, 
                        300 
                ], 
                [ 
                        100, 
                        110 
                ] 
        ] 
}

These two commands should find this element but they don't:

> db.test.find({"field": {$elemMatch: {0: 100, 1:300}}}) 
> db.test.find({"field": {$elemMatch: {0: {$gt: 1}, 1: {$gt: 1}}}}) 



 Comments   
Comment by Ramon Fernandez Marina [ 12/Feb/18 ]

This was fixed back in 2.6, but closing the ticket fell through the cracks.

Comment by Thomas Zahn [ 14/Feb/14 ]

As a consequence, this unfortunately also affects the work-around to detect instances where a field a is an array, as suggested in SERVER-1475:

db.test1.find({$or: [{"a": {$size: 0}}, {"a": {$elemMatch: {$exists: true}}}]})

It won't work for nested arrays.

mongos> db.test1.find()
{ "_id" : ObjectId("52fcf0e3f067bdb1472ebeef"), "a" : [  7,  10 ] }
{ "_id" : ObjectId("52fcf0e3f067bdb1472ebef0"), "a" : [  1,  2,  3 ] }
{ "_id" : ObjectId("52fcf0e3f067bdb1472ebef1"), "a" : [  [  10,  11 ],  [  20,  21 ] ] }
{ "_id" : ObjectId("52fcf0e3f067bdb1472ebef2"), "a" : [  [  1 ],  [  2 ],  [  3 ] ] }
{ "_id" : ObjectId("52fcf0e3f067bdb1472ebef3"), "a" : [  [ ] ] }

Suppose one now wanted to explicitly find those documents where a specific element of a (e.g. a.0) is again an array, i.e. a 2-dimensional array. Unfortunately, only $size seems to work on a.0, whereas $elemMatch fails:

mongos> db.test1.find({$or: [{"a.0": {$size: 0}}, {"a.0": {$elemMatch: {$exists: true}}}]})
{ "_id" : ObjectId("52fcf0e3f067bdb1472ebef3"), "a" : [  [ ] ] }
mongos> db.test1.find({"a.0": {$size: 0}})
{ "_id" : ObjectId("52fcf0e3f067bdb1472ebef3"), "a" : [  [ ] ] }
mongos> db.test1.find({"a.0": {$elemMatch: {$exists: true}}})
mongos>

Comment by auto [ 09/Jun/12 ]

Author:

{u'login': u'astaple', u'name': u'Aaron', u'email': u'aaron@10gen.com'}

Message: SERVER-4180 Generate single key index bounds for $elemMatch expressions of the SERVER-1264 style (where matching is applied to the $elemMatch field itself, not subfields).
Branch: master
https://github.com/mongodb/mongo/commit/bb0fd337ac9498a5642986bba162880fa3030ce0

Comment by auto [ 09/Jun/12 ]

Author:

{u'login': u'astaple', u'name': u'Aaron', u'email': u'aaron@10gen.com'}

Message: SERVER-4180 Fixes and cleanups for $elemMatch index range calculation, in particular to clean up incorrect bound generation for SERVER-1264 style $elemMatch queries. Includes fixes for SERVER-5740 and SERVER-5741.
Branch: master
https://github.com/mongodb/mongo/commit/2b572b9c07d8d3feda949153e20b9eee8706ff7d

Comment by Aaron Staple [ 05/Apr/12 ]

Robert identified some additional todos for supporting the full range of mongo query operators inside $elemMatch. He described them in SERVER-5506.

Comment by auto [ 13/Sep/11 ]

Author:

{u'login': u'astaple', u'name': u'Aaron', u'email': u'aaron@10gen.com'}

Message: SERVER-1264 update test
Branch: master
https://github.com/mongodb/mongo/commit/5410320e7c70616f3321f76859f8575a68230dd3

Comment by auto [ 15/Nov/10 ]

Author:

{'login': 'erh', 'name': 'Eliot Horowitz', 'email': 'eliot@10gen.com'}

Message: notes for SERVER-1264
/mongodb/mongo/commit/b683f36c7dbb006a853b6002188926337db0c5b4

Comment by Piotr Beling [ 24/Sep/10 ]

I understand. Thanks!

Comment by Eliot Horowitz (Inactive) [ 24/Sep/10 ]

No - we won't backport this.
This is borderline bug vs. feature.
$elemMatch was originally never intended to be used for primitives, so the behavior was undefined.

Comment by Piotr Beling [ 24/Sep/10 ]

Can I ask for back-port fixes to 1.6 brunch? I think that this is typical bug and it is good idea to back-port it to stable brunch.

Comment by auto [ 24/Sep/10 ]

Author:

{'login': 'erh', 'name': 'Eliot Horowitz', 'email': 'eliot@10gen.com'}

Message: $elemMatch works on primitives SERVER-1264
still some issues with indexes though
http://github.com/mongodb/mongo/commit/193fbaf47a67db4602814f2a1f1cb8468b362d90

Comment by Eliot Horowitz (Inactive) [ 25/Aug/10 ]

db.foo.save(

{a:[1, 2, 6]}

)
db.foo.save(

{a:[1, 4, 6]}

)

> db.foo.find( {a:{$elemMatch:{$gte:3, $lte: 5}}} )

Generated at Thu Feb 08 02:56:33 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.