[SERVER-2746] Geo-indexing + Max fails when max is very large Created: 11/Mar/11  Updated: 12/Jul/16  Resolved: 15/Mar/11

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 1.8.0-rc2
Fix Version/s: 1.9.0

Type: Improvement Priority: Minor - P4
Reporter: Gaetan Voyer-Perrault Assignee: Greg Studer
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu and Windows


Participants:

 Description   

To repro run the following commands against an empty db.

> db.tri.ensureIndex(

{ c: '2d', t: 1 }

,

{ min: 0, max: Math.pow(2, 40) }

)
> db.tri.insert(

{ c : [1,1], t : 1}

)
point not in range
> db.system.indexes.find()
{ "name" : "id", "ns" : "localhost.tri", "key" :

{ "_id" : 1 }

, "v" : 0 }
{ "_id" : ObjectId("4d796ffa3996d83589c67397"), "ns" : "localhost.tri", "key" :

{ "c" : "2d", "t" : 1 }

, "name" : "c__t_1", "min" : 0, "max" : 1099511627776 }

So we're creating a Geo index with a very large max. It's obviously not too large as the index correctly saves / displays the number. However, when we insert data, that index throws the "point not in range" error.

Math.pow(2,30) => works correctly
Math.pow(2,31) => breaks

(integer vs numberlong issue?)



 Comments   
Comment by Greg Studer [ 14/Mar/11 ]

Updated to disallow index creation with very large/small bounds, higher-precision 2d indexing would be a new feature.

Comment by auto [ 14/Mar/11 ]

Author:

{u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}

Message: Changes for SERVER-2746
https://github.com/mongodb/mongo/commit/f027a8dbc746412ea4b45a3a6563d4f591059b06

Comment by auto [ 14/Mar/11 ]

Author:

{u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}

Message: New test for SERVER-2746
https://github.com/mongodb/mongo/commit/4b3f73ee93defb897a2dcea1696776be377544c8

Comment by Greg Studer [ 14/Mar/11 ]

Thanks for the helpful test, you are correct, the issue is that the maximum precision in the 2d indexing is 32 bits, and therefore uses integers for max and min bounds. The index is actually not storing the large values correctly, they overflow, but the db.system.indexes collection stores the javascript data from the call itself.

There should be a more helpful error message provided, however, as it is not at all obvious what's going on otherwise.

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