-
Type: Bug
-
Resolution: Done
-
Priority: Major - P3
-
None
-
Affects Version/s: 2.5.5
-
Component/s: Querying
-
Labels:
-
Environment:> db.serverBuildInfo()
{
"version" : "2.5.6-pre-",
"gitVersion" : "0c065ec66101960e27b4c6cff7f224ec74b8bfed",
"OpenSSLVersion" : "",
"sysInfo" : "Darwin bs-osx-108-x86-64-2.10gen.cc 12.3.0 Darwin Kernel Version 12.3.0: Sun Jan 6 22:37:10 PST 2013; root:xnu-2050.22.13~1/RELEASE_X86_64 x86_64 BOOST_LIB_VERSION=1_49",
"loaderFlags" : "-fPIC -pthread -Wl,-bind_at_load -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 -Wno-unused-function -Wno-deprecated-declarations -mmacosx-version-min=10.6",
"allocator" : "system",
"versionArray" : [
2,
5,
6,
-100
],
"javascriptEngine" : "V8",
"bits" : 64,
"debug" : false,
"maxBsonObjectSize" : 16777216,
"ok" : 1
}> db.serverBuildInfo() { "version" : "2.5.6-pre-", "gitVersion" : "0c065ec66101960e27b4c6cff7f224ec74b8bfed", "OpenSSLVersion" : "", "sysInfo" : "Darwin bs-osx-108-x86-64-2.10gen.cc 12.3.0 Darwin Kernel Version 12.3.0: Sun Jan 6 22:37:10 PST 2013; root:xnu-2050.22.13~1/RELEASE_X86_64 x86_64 BOOST_LIB_VERSION=1_49", "loaderFlags" : "-fPIC -pthread -Wl,-bind_at_load -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 -Wno-unused-function -Wno-deprecated-declarations -mmacosx-version-min=10.6", "allocator" : "system", "versionArray" : [ 2, 5, 6, -100 ], "javascriptEngine" : "V8", "bits" : 64, "debug" : false, "maxBsonObjectSize" : 16777216, "ok" : 1 }
-
Query
-
ALL
-
From the documentation of $type:
If the field holds an array, the $type operator performs the type check against the array elements and not the field.
Unfortunately, the $type operator does not seem to get properly applied if the field is itself a concretely named (dot notation) (first-level) array element.
Consider these arrays:
> db.test1.find() { "_id" : ObjectId("5301dd9721e397fc8e5b537c"), "a" : [ [ "aa", "ab", "ac" ], [ 10, 11, 12 ] ] } { "_id" : ObjectId("5301dd9721e397fc8e5b537d"), "a" : [ [ "ba", "bb", "bc" ], [ 20, 21, 22 ] ] } { "_id" : ObjectId("5301dd9721e397fc8e5b537e"), "a" : [ [ "ca", "cb", "cc" ], [ 30, 31, 32 ] ] } >
Suppose one now wanted to find those documents where the specific first-level element a.0 is itself an array and contains String elements:
> db.test1.find({ "a.0" : { "$type" : 2}}) >
Nothing comes up even though a.0 contains String elements in all documents.
Note that trying to achieve this via the $elemMatch route does work:
> db.test1.find({ "a" : {"$elemMatch" : { "0" : {"$type" : 2}}}}) { "_id" : ObjectId("5301dd9721e397fc8e5b537c"), "a" : [ [ "aa", "ab", "ac" ], [ 10, 11, 12 ] ] } { "_id" : ObjectId("5301dd9721e397fc8e5b537d"), "a" : [ [ "ba", "bb", "bc" ], [ 20, 21, 22 ] ] } { "_id" : ObjectId("5301dd9721e397fc8e5b537e"), "a" : [ [ "ca", "cb", "cc" ], [ 30, 31, 32 ] ] } >
However, it seems rather inefficient to first apply a check for a "field" 0 on potentially all array elements of a when one already knows the concrete element to investigate.
(On a side note, I have always found it rather peculiar that $type is applied to the elements of an array field rather than to the field itself when {"$elemMatch" : {"$type" : <id>}} already captures these desired semantics)
This seems somewhat related to SERVER-11455.