[SERVER-11429] Not trapping mismatch between data value and data type Created: 28/Oct/13  Updated: 10/Dec/14  Resolved: 29/Oct/13

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: 2.4.5
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Alvin Richards (Inactive) Assignee: Unassigned
Resolution: Done Votes: 0
Labels: 26qa, nqf
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

{
"version" : "2.5.4-pre-",
"gitVersion" : "d8ca8b5faa1447365403cfb8da16a041e7d31d95",
"OpenSSLVersion" : "",
"sysInfo" : "Darwin vero 12.5.0 Darwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~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 -Wno-unknown-pragmas -Winvalid-pch -pipe -O3 -Wno-unused-function -Wno-deprecated-declarations -mmacosx-version-min=10.6",
"allocator" : "tcmalloc",
"versionArray" : [
2,
5,
4,
-100
],
"javascriptEngine" : "V8",
"bits" : 64,
"debug" : false,
"maxBsonObjectSize" : 16777216,
"ok" : 1
}


Issue Links:
Related
Operating System: ALL
Participants:

 Description   

2.5.x is not throwing an error when there is a comparison between the data vale and datatype of the same attribute. For example data value of ISODate("2013-09-29T10:40Z") (type 9) and compared against data type 17 (Timestamp).

Reproduce:

db.q.drop()
db.q.insert({ "c" : ISODate("9999-12-31T00:00:00Z") })
db.q.find( { "c" : { $gt : ISODate("2013-09-29T10:40Z") , $type : 17 } } )

2.4.5

error: { "$err" : "wrong type for field () 17 != 9", "code" : 13111 }

2.5.4-Pre
Zero results returned



 Comments   
Comment by Eliot Horowitz (Inactive) [ 29/Oct/13 ]

{ a :

{ $gt : 5 , $lt : 4 }

} is not an error, so neither should this

Comment by Alvin Richards (Inactive) [ 29/Oct/13 ]

The way I read this query is an "and", but causes a condition that cannot be true, i.e. data value of type Date and type of Timestamp.

Throwing an error is at least backward compatible.

New behaviour seems to provide a consistent behaviour.

Its subjective (in IMHO) what is the correct behaviour, so Im OK to go with eliot opinion. Does this have an unexpected side-effects?

Comment by Eliot Horowitz (Inactive) [ 29/Oct/13 ]

The query language always lets you do a query comparing types, and you just don't get matches.
The new behavior seems to fix an edge case in that logic.

Comment by Daniel Pasette (Inactive) [ 29/Oct/13 ]

The 2.4 behavior is more informative in that you have incompatible types in the query.

Comment by Scott Hernandez (Inactive) [ 28/Oct/13 ]

Alvin, you think the current behavior is a bug (and preferred behavior), not just a behavior change?

Comment by Alvin Richards (Inactive) [ 28/Oct/13 ]

Another example

db.q.drop()
db.q.insert({ "c" : Timestamp(42,7) })
db.q.find( { "c" : { $gt : ISODate("2013-09-29T10:40Z"), $type : 17 } } )

2.4.5

error: { "$err" : "wrong type for field () 17 != 9", "code" : 13111 }

2.5.4-Pre
Returns zero documents

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