Sign In Register

How can we help you today?

Start a new topic
Answered

NumberLong

How can I store a 64-bit integer in a collection? Typically one uses the NumberLong constructor but that doesn't appear to be available in Cloud Code. Is there another way to do it?


Best Answer

Hi Jay,


We don't currently have support for 64 bit integers through cloud code, but if you could provide us with a little more detail we may be able to help you achieve the behaviour you require:


- What are these numbers to be used for (are they identifiers, will there be arithmetic operations being performed on them)?

- Why is it a requirement that these numbers be 64 bit ints?


Regards,

Vinnie


Answer

Hi Jay,


We don't currently have support for 64 bit integers through cloud code, but if you could provide us with a little more detail we may be able to help you achieve the behaviour you require:


- What are these numbers to be used for (are they identifiers, will there be arithmetic operations being performed on them)?

- Why is it a requirement that these numbers be 64 bit ints?


Regards,

Vinnie

These are transaction IDs for microtransactions. It is a unique ID that starts at 1 and needs to be atomically incremented in order to get the next unique transaction ID.


Considering that one of these is generated when a transaction is initiated (regardless of whether or not anything is actually purchased) I could see this feasibly overflowing a 32-bit integer and the API I'm interfacing with assumes a 64-bit transaction ID as well.

So I ran into this issue early on with Gamesparks as well, having not much server/db experience. 


Cloud code is in JS which means all numbers are 64-bit floating point double precision numbers. That means when you set it to a field in a document, it will be treated as a double by mongo (BSON type).  You can force mongo to treat the number as a long by setting the value of a field like so, where 'x' is a string of the digits of the number: 

field : { "$numberLong" : x }

But I've seen it do weird things to the rest of my doubles (like convert some or all of my other double type values in the document to also be wrapped in '$numberLong'). Additionally, it still means you're converting from float to int to get it stored that way on the db. You're not avoiding the conversion, you're just doing it sooner and causing more headache. 


So I too need unique ids that potentially cross the 32 bit int max value in my Unity game, and I've had no problem just converting the double back to long on the client. In fact Gamepsarks api for Unity has a getLong("field name") method for GSData objects that does the conversion for you. Just be aware that you lose integer precision at 2^53, so you don't get full use of 64 bits, but if you've used ~9 quadrillion unique ids, your business is probably successful enough to work out another solution at that point.


So to clarify, I see your problem as having two separate issues:


1) You need >32 bits of entropy

2) You'd like the type to be a (long) int rather than a (double) float for the APIs sake


1) is already satisfied automatically by mongo. Any number in cloude code *will* be saved as a double. 2) is just simply not cleanly possible because javascript doesn't have an int number type so some conversion will have to take place, and in my opinion the best place to do that is *after* you get the number from mongo on whatever platform you get the result before you send it to the 3rd party api.


I hope I've helped and someone please correct me if I've misunderstood something about all this myself.

Appreciate the reply Ryan!


I actually tried to do what you suggested:

{ field: { "$numberLong": "12345" } }

 and it didn't work, although maybe it was because I was attempting to set it as a string?


I'm currently doing what you suggested and just hoping nothing breaks. Would love proper support for 64-bit integers...

Hmm that's weird. As I said it always behaved oddly for me as well. And I only tried adding that directly in the NoSQL explorer, so maybe through cloud code you need the number/string in some other type.


And I agree. it feels dirty to be using floats for something like IDs.

Login to post a comment