NumberInt changes to NumberLong

[jmkgreen]

If you go to update any document featuring a NumberInt and merely hit Update (without making any changes), the field type is now set to NumberLong. This causes ClassCastExceptions in Java, and I imagine quite a few similar problems in other langauges.

[iwind]

Fail to re-produce the problem. If you did not click "Apply" button, the document should not be changed.

[matb33]

This is happening to me as well. I even tried manually replacing all instances of NumberLong to NumberInt, hit save, and it still converts to NumberLong.

I tried doing an insert of this document:

{
  "test": NumberInt(1)
}

And the result is:

{
  "test": NumberLong(1)
}

I am using Rockmongo 1.1.5. This was also occuring in 1.1.2. Additional info:

Connection
Host    127.0.0.1
Port    3002

Web Server
Web server  Apache/2.2.22
PHP version PHP 5.4.9-4ubuntu2.2
PHP extension   mongo/1.2.12

Directives
Directive   Global Value    Local Value
mongo.allow_empty_keys  0   0
mongo.allow_persistent  1   1
mongo.chunk_size    262144  262144
mongo.cmd   $   $
mongo.default_host  localhost   localhost
mongo.default_port  27017   27017
mongo.is_master_interval    60  60
mongo.long_as_object    0   1
mongo.native_long   0   1
mongo.no_id 0   0
mongo.ping_interval 5   5
mongo.utf8  1   1

[matb33]

From the debugging I've done, it appears to be caused by PHP's MongoCollection.update() function. @iwind, your code looks fine IMO.

I inserted a simple test document with NumberInt, which became NumberLong:

{
  "test": NumberLong(1)
}

When trying to update it and change NumberLong to NumberInt, I did a var_dump($this->_operations); just above this line: https://github.com/iwind/rockmongo/blob/master/app/lib/mongo/RObject.php#L213

The dump looked correct: array(1) { ["$set"]=> array(1) { ["test"]=> int(1) } }

At this point, it's all in the hands of MongoCollection, so this looks like a bug on their end. I have to stop chasing this down due to time constraints, hoping someone else can take the lead.

[ritikm]

I'm also encountering this problem with Rockmongo (and other Mongo Admin UIs -- MongoHub, RoboMongo, etc.). It seems like the way that MongoDB is handling the update() call is turning all large numbers from being interpreted as a Double to a Long. Normally this wouldn't be a problem except certain frameworks aren't receptive to this change (i.e. Meteor.js fails to interpret a Long correctly but can handle Doubles just fine). Is there any way to fix this issue without having to revert to an older MongoDB version?

[matb33]

I used Robomongo to correct my document successfully. Are you sure this bug is applicable to all MongoDB admin UIs? I assumed the issue lied within PHP's implementation

[ritikm]

You're right. Inserting a document directly in RoboMongo doesn't cause this error. i.e. if you insert a document like { "createdAt": 1376438673414 }, RoboMongo will parse it as a 64-bit integer (which gets interpreted as a Long); however, if you edit a pre-existing document with a Double value, RoboMongo will typecast the Double value as a 64-bit Integer (Long), which makes me believe that the problem isn't just unique to RockMongo or PHP's implementation.

This problem didn't exist in earlier builds (pre-July) of MongoDB, and I remember finding out that recent versions of Mongo's BSON parser changed the way it parses Numbers. Before, the example I mention above would get parsed as a Double, but now it gets interpreted as a Long, which is probably something similar to what you're seeing.

There might be a way to get around this by forcing all Numbers to be interpreted as Doubles (add 0.0 to every number).

[jmkgreen]

I don't believe it's a problem as a result of upgrading mongodb: we upgraded a demo cluster from 2.2 to 2.4 to ensure everything was up to date prior to filing this bug.

However, could the issue lay within the php mongo driver perhaps? I'm on holiday at present and don't have time to investigate this until next week at earliest.

James

Sent from my iPad

On 15 Aug 2013, at 00:11, Ritik Malhotra [email protected] wrote:

You're right. Inserting a document directly in RoboMongo doesn't cause this error. i.e. if you insert a document like { "createdAt": 1376438673414 }, RoboMongo will parse it as a 64-bit integer (which gets interpreted as a Long); however, if you edit a pre-existing document with a Double value, RoboMongo will typecast the Double value as a 64-bit Integer (Long), which makes me believe that the problem isn't just unique to RockMongo or PHP's implementation.

This problem didn't exist in earlier builds (pre-July) of MongoDB, and I remember finding out that recent versions of Mongo's BSON parser changed the way it parses Numbers. Before, the example I mention above would get parsed as a Double, but now it gets interpreted as a Long, which is probably something similar to what you're seeing.

There might be a way to get around this by forcing all Numbers to be interpreted as Doubles (add 0.0 to every number).

— Reply to this email directly or view it on GitHub

[jmkgreen]

See also http://php.net/manual/en/mongo.types.php and an upcoming change to a default value.

[stefanocudini]

Vote on this issue please #133