[SERVER-1735] Inconsistent behaviour for $exists: false and $type: 10 in query Created: 04/Sep/10 Updated: 12/Jul/16 Resolved: 03/Jun/11 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 1.6.1, 1.6.2, 1.7.0 |
| Fix Version/s: | 1.9.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Andrea Spacca | Assignee: | Aaron Staple |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Tested as bogus in macosx 10.6.4 server 64bit and Ubuntu 9.10 64bit |
||
| Issue Links: |
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
key: {$exists: false} / key: {$type: 10} / key: null quering gives inconsistent and unpredictable behaviour, so to workraound needed to implement querying of this kind of parameters shell script example: , {unique: 1, background: 1}); ); ); ); ); ); ); db.testcollection.find( {date: new Date("08/27/2010")}).count(); // 6 [OK] ).count(); // 1 [OK] changing the order of key querying or indexing produces slightly different results, always bogus |
| Comments |
| Comment by auto [ 03/Jun/11 ] |
|
Author: {u'login': u'astaple', u'name': u'Aaron', u'email': u'aaron@10gen.com'}Message: |
| Comment by Aaron Staple [ 03/Jun/11 ] |
|
Our behavior now is {a:null} - match if a is null or missing |
| Comment by auto [ 02/Jun/11 ] |
|
Author: {u'login': u'astaple', u'name': u'Aaron', u'email': u'aaron@10gen.com'}Message: |
| Comment by Aaron Staple [ 05/Apr/11 ] |
|
The exists:false failure is |
| Comment by Guanqun Lu [ 28/Jan/11 ] |
|
come up with a more compact fix, as this type info is already maintained in bm. https://github.com/mongodb/mongo/pull/14/ any comments? |
| Comment by Guanqun Lu [ 13/Jan/11 ] |
|
I did some hacking on this problem and found db/matcher.cpp bool Matcher::matches(const BSONObj& jsobj , MatchDetails * details ) 764 if ( cmp == 0 ) { at line 766 shown above, for ElementMatcher { $type : 10 }to match user_id, at this point, m.type() is NumberDouble (value is 10.0), and the compareOp is 15 (opTYPE). we should take this case into consideration because we're actually looking for null. the corresponding fix is here. and i've added a jstest for this bug. please review, |
| Comment by Doug Mayer [ 03/Nov/10 ] |
|
The following line is noted as OK above: db.testcollection.find({date: new Date("08/27/2010"), country_code: {$exists: true}, user_id: {$exists: false}}).count(); // 2 [OK] On Mac OSX 64-bit, v1.6.3, this line actually returns ZERO records. There seems to be a lot of inconsistent behavior around $exists in 1.6. |