[SERVER-8699] 2d suitability() is inconsistent with newCursor() in certain nested field cases Created: 25/Feb/13  Updated: 10/Dec/14  Resolved: 18/Apr/14

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

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

Operating System: ALL
Participants:

 Description   

Geo2dType::suitability() uses getFieldsDotted() to extract a geo field from a query. I don't believe this is correct, because getFieldsDotted() recursively extracts fields from nested objects, and query fields use dotted top level and not nested fields.

Eg to query field 'a.b' you would write a query

{ 'a.b':5 }

not { a:

{ b:5 }

}. The latter is an equality predicate on 'a' not on 'a.b'.

Geo2dType::newCursor() looks for a geo index field name in a query without expanding nested document field names (I believe correctly).

This appears to cause a problem in cases where suitability() is inconsistent with newCursor() - suitability() says the index is not useless, but newCursor() asserts when trying to create a cursor on the index.

We should also check the s2 code to see if the same issue is present there.

Test

c = db.c;
c.drop();
 
c.save( { a:{ loc:[ 0, 0 ], b:5 } } );
// Count works as expected without an index.                                    
assert.eq( 0, c.count( { a:{ loc:[ 0, 0 ] } } ) );
 
c.ensureIndex( { 'a.loc':'2d' } );
// Count asserts with a 2d index.                                               
assert.eq( 0, c.count( { a:{ loc:[ 0, 0 ] } } ) );

Error

Sun Feb 24 18:03:00.854 JavaScript execution failed: count failed: {
	"errmsg" : "exception: missing geo field (a.loc) in : { a: { loc: [ 0.0, 0.0 ] } }",
	"code" : 13042,
	"ok" : 0
} at src/mongo/shell/query.js:L180



 Comments   
Comment by Greg Studer [ 18/Apr/14 ]

New query framework has replaced this functionality.

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