[SERVER-8010] Query anomaly with Date and Timestamp Created: 21/Dec/12  Updated: 07/Apr/23  Resolved: 26/Dec/12

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

Type: Bug Priority: Major - P3
Reporter: Christoph Bussler Assignee: Aaron Staple
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-3304 Change comparison order so all Dates ... Closed
Operating System: ALL
Steps To Reproduce:

// 1. Querying with timestamp only (works)
var ts = db.getCollection( "timestamp" );
ts.save(

{ "_id" : 1, "x" : Timestamp(2000, 1) }

);
assert.eq( ts.count(

{ "x" : Timestamp(2000, 1 ) }

), 1 );

// 2. After adding a document with date, the same query fails with message: error:

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

ts.save(

{ "_id" : 2, "x" : ISODate("2012-08-31T12:13:14.156Z") }

);
assert.eq( ts.count(

{ "x" : Timestamp(2000, 1 ) }

), 1 );

Participants:

 Description   

When querying for timestamp, an error happens when a different document containing date is present, but works if date is not present.

(Just as a remark upfront, I don't have control over the databases and cannot enforce conventions)

Server logs:

Sun Dec 23 19:38:51.844 [conn1] Assertion: 13111:wrong type for field (x) 17 != 9
0x10811e14b 0x1080f8b9e 0x1080f8c5d 0x107da2358 0x107d854ab 0x107f1bd7c 0x107f11057 0x107f1182a 0x107f1d640 0x107f1d86a 0x107faa870 0x107f37335 0x107f378e7 0x107f3a876 0x107ee3aff 0x107d34d62 0x108113ee1 0x108150775 0x7fff948848bf 0x7fff94887b75 
 0   mongod                              0x000000010811e14b _ZN5mongo15printStackTraceERSo + 43
 1   mongod                              0x00000001080f8b9e _ZN5mongo11msgassertedEiPKc + 174
 2   mongod                              0x00000001080f8c5d _ZN5mongo11msgassertedEiRKSs + 29
 3   mongod                              0x0000000107da2358 _ZNK5mongo11BSONElement3chkEi + 760
 4   mongod                              0x0000000107d854ab _ZN5mongo20compareElementValuesERKNS_11BSONElementES2_ + 651
 5   mongod                              0x0000000107f1bd7c _ZNK5mongo7Matcher11valuesMatchERKNS_11BSONElementES3_iRKNS_14ElementMatcherE + 100
 6   mongod                              0x0000000107f11057 _ZNK5mongo7Matcher13matchesDottedEPKcRKNS_11BSONElementERKNS_7BSONObjEiRKNS_14ElementMatcherEbPNS_12MatchDetailsE + 3431
 7   mongod                              0x0000000107f1182a _ZNK5mongo7Matcher7matchesERKNS_7BSONObjEPNS_12MatchDetailsE + 314
 8   mongod                              0x0000000107f1d640 _ZNK5mongo19CoveredIndexMatcher7matchesERKNS_7BSONObjERKNS_7DiskLocEPNS_12MatchDetailsEb + 464
 9   mongod                              0x0000000107f1d86a _ZNK5mongo19CoveredIndexMatcher14matchesCurrentEPNS_6CursorEPNS_12MatchDetailsE + 212
 10  mongod                              0x0000000107faa870 _ZN5mongo6Cursor14currentMatchesEPNS_12MatchDetailsE + 56
 11  mongod                              0x0000000107f37335 _ZN5mongo20QueryResponseBuilder8addMatchEv + 121
 12  mongod                              0x0000000107f378e7 _ZN5mongo23queryWithQueryOptimizerEiRKSsRKNS_7BSONObjERNS_5CurOpES4_S4_RKN5boost10shared_ptrINS_11ParsedQueryEEES4_RKNS_17ShardChunkVersionERNS7_10scoped_ptrINS_25PageFaultRetryableSectionEEERNSG_INS_19NoPageFaultsAllowedEEERNS_7MessageE + 1255
 13  mongod                              0x0000000107f3a876 _ZN5mongo8runQueryERNS_7MessageERNS_12QueryMessageERNS_5CurOpES1_ + 5158
 14  mongod                              0x0000000107ee3aff _ZN5mongo16assembleResponseERNS_7MessageERNS_10DbResponseERKNS_11HostAndPortE + 1599
 15  mongod                              0x0000000107d34d62 _ZN5mongo16MyMessageHandler7processERNS_7MessageEPNS_21AbstractMessagingPortEPNS_9LastErrorE + 196
 16  mongod                              0x0000000108113ee1 _ZN5mongo17PortMessageServer17handleIncomingMsgEPv + 1697
 17  mongod                              0x0000000108150775 thread_proxy + 229
 18  libsystem_c.dylib                   0x00007fff948848bf _pthread_start + 335
 19  libsystem_c.dylib                   0x00007fff94887b75 thread_start + 13



 Comments   
Comment by Aaron Staple [ 26/Dec/12 ]

This is SERVER-3304, not a regression from 2.0.

The change from 2.0 is that in 2.0 (and prior), when an error occurred during a count, a count value of 0 was returned instead of an error. In 2.2, an error is now sent to the client (the behavior is now consistent with find). This change was SERVER-2291.

You can see that the same issue is present in 2.0 by changing the count( x ) to a find( x ).itcount() in the supplied test and running against 2.0.

c = db.c;
c.drop();
 
c.save( { "_id" : 1, "x" : Timestamp(2000, 1) } );
assert.eq( c.find( { "x" : Timestamp(2000, 1 ) } ).itcount(), 1 );
 
c.save( { "_id" : 2, "x" : ISODate("2012-08-31T12:13:14.156Z") } );
assert.eq( c.find( { "x" : Timestamp(2000, 1 ) } ).itcount(), 1 );

MongoDB shell version: 2.3.2-pre-
connecting to: test
Wed Dec 26 11:05:46.013 exec error: src/mongo/shell/query.js:128 error: { "$err" : "wrong type for field (x) 17 != 9", "code" : 13111 }
throw "error: " + tojson( ret );
                ^
 
failed to load: test.js

Comment by Daniel Pasette (Inactive) [ 26/Dec/12 ]

this is a regression from 2.0 and still present in 2.3.1.

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