Storing 'long' type in firebase

Question

We have an iPhone application that is backed by Core Data. We use int64 in our core data store and I am wondering if we need to do anything special to store the number in firebase. I am wondering about this as javascript does not support 64 bit unsigned integers. We also are writing a javascript app that will have to read this number.

One approach I can think of is to store this as string and then convert it to int64 on the iPhone client. However this seems little bit tedious and firedata does not seem to support such translations directly. We will also have to add validation on this attribute in Firebase - so the validation would be that instead of a number it will be a string with only digits.

Has anyone encountered these issues and what would be the recommended approach for this issue ?

Answer 1

This can indeed be a tricky situation. First just to make the situation clear (I think you are aware of this, but just to avoid any confusion):

• Firebase can/will store 64-bit integers precisely.
• Android and iOS clients can interact (read and write) 64-bit integers without issue.
• JavaScript stores all numbers as 64-bit floating point numbers, meaning it can only represent integers up to ~2^52 precisely. Integers between 2^52 and 2^64 may lose precision (get rounded to the nearest integer representable by a 64-bit float).

As for your options, I suspect you have a good handle on these as well, but you could:

• Tolerate the loss of precision. Sometimes this is okay. For example, maybe you can guarantee you won't store integers over 2^52, so the loss of precision won't actually be an issue. Or maybe you only need to view the data from JS and some rounding is okay. One thing to be careful of is if you read the data from JS and write it back, the data will be written back to Firebase with a loss in precision.
• Store the numbers as strings. As you suggested, you can just store the number as a string. But this can be inconvenient and does limit the validation you can do in the security rules.
• Split the number into 2 32-bit integers. You could store the upper 32-bits separately from the lower 32-bits. This is probably inconvenient, but would allow you to keep precision and also do some numeric validation in security rules.

There may be other options, but these are the ones that immediately come to mind. Hope this helps!