[SERVER-11785] $all with nested array behaves differently in 2.4 v 2.5 Created: 20/Nov/13  Updated: 10/Dec/14  Resolved: 23/Dec/13

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: 2.5.3, 2.5.4
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Luke Lovett Assignee: David Storch
Resolution: Done Votes: 0
Labels: 26qa, nqf
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

> db.serverBuildInfo()
{
"version" : "2.4.9-pre-",
"gitVersion" : "5779b6e198c0dd22a99e12837faea4b5e8b2664f",
"sysInfo" : "Darwin bs-osx-106-x86-64-2.10gen.cc 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64 BOOST_LIB_VERSION=1_49",
"loaderFlags" : "-fPIC -pthread -rdynamic -m64",
"compilerFlags" : "-Wnon-virtual-dtor -Woverloaded-virtual -fPIC -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -O3 -m64",
"allocator" : "system",
"versionArray" : [
2,
4,
9,
-100
],
"javascriptEngine" : "V8",
"bits" : 64,
"debug" : false,
"maxBsonObjectSize" : 16777216,
"ok" : 1
}
and
> db.serverBuildInfo()
{
"version" : "2.5.5-pre-",
"gitVersion" : "9795d501bb74edcfbcd518300fd1b96e4f2856e1",
"OpenSSLVersion" : "",
"sysInfo" : "Darwin bs-osx-106-x86-64-2.10gen.cc 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64 BOOST_LIB_VERSION=1_49",
"loaderFlags" : "-fPIC -pthread -Wl,-bind_at_load -m64 -mmacosx-version-min=10.6",
"compilerFlags" : "-Wnon-virtual-dtor -Woverloaded-virtual -fPIC -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -Werror -pipe -O3 -m64 -Wno-unused-function -Wno-deprecated-declarations -mmacosx-version-min=10.6",
"allocator" : "system",
"versionArray" : [
2,
5,
5,
-100
],
"javascriptEngine" : "V8",
"bits" : 64,
"debug" : false,
"maxBsonObjectSize" : 16777216,
"ok" : 1
}


Issue Links:
Related
related to DOCS-2454 document behavior change to $all: now... Closed
Operating System: ALL
Steps To Reproduce:

2.5.5-pre-

> db.c.insert({a:["red","blue"]})
> db.c.insert({a:["red"]})
> db.c.count({a:{$all:[["red"]]}})
{ "_id" : ObjectId("528c0a6e1d37e39f262901af"), "a" : [  "red" ] }
> db.c.count({a:{$all:["red"]}})
{ "_id" : ObjectId("528c0a661d37e39f262901ae"), "a" : [  "red",  "blue" ] }
{ "_id" : ObjectId("528c0a6e1d37e39f262901af"), "a" : [  "red" ] }

2.4.9-pre-

> db.c.insert({a:["red","blue"]})
> db.c.insert({a:["red"]})
> db.c.find({a:{$all:[["red"]]}})
> db.c.find({a:{$all:["red"]}})
{ "_id" : ObjectId("528c0a3b679ed5d9487c0be4"), "a" : [  "red",  "blue" ] }
{ "_id" : ObjectId("528c0a44679ed5d9487c0be5"), "a" : [  "red" ] }

Participants:

 Description   

The $all query operator can return different results in 2.4 v 2.5 versions of mongodb when given a nested array as an argument. Not sure which behavior is "correct" here, but want to confirm that this change is intentional and that this change gets documented somewhere (and this may become a DOCS ticket).



 Comments   
Comment by hari.khalsa@10gen.com [ 27/Dec/13 ]

david.storch yup we rewrite $all as $and when possible.

Comment by David Storch [ 23/Dec/13 ]

The $all operator has two interpretations:

  1. In order to match the document, the target field must be an array which has as elements each of the elements specified by the $all.
  2. The $all operator is syntactic sugar for $and.

In most cases these two interpretations are identical, but not so for the query

db.c.find({a:{$all:[["red"]]}})

The old query system used interpretation #1: in order to match, field 'a' must be an array which has the array

["red"]

as one of its elements. On the other hand, it looks like the new query system is using interpretation #2, namely that the query can be rewritten as

{$and: [{a: ["red"]}]}

which in turn simplifies to

{a: ["red"]}

The final document matches due to literal array equality.

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