Class Type changing on sync recipient

[James Norman]

I'm storing a long in the properties map of a local database and syncing that with others.  In the local database it is returned as a Long which is correct, but when synced to other databases it is returned as a Double.  Here's the code I used to verify this, very brief:

Storing on a local database:

properties.put( "test2", System.currentTimeMillis() );

Print on the local database I just stored on:

08-14 09:33:06.260    5957-5957/com.assayrt I/System.out﹕ typeeeeee: java.lang.Long

Same documentId retrieved as the result of a sync and I get this for the type

08-14 09:21:25.130    3572-3631/com.assayrt I/System.out﹕ typeeeeee: java.lang.Double

I'm not sure if this is the desired behavior or not.  If not I can file a bug for it, and if so let me know the best strategy for handling this.  I have a workaround I can use in the mean time.

Thanks -james

[Jens Alfke]

On Aug 14, 2014, at 6:38 AM, James Norman <james....@gmail.com> wrote:

I'm storing a long in the properties map of a local database and syncing that with others.  In the local database it is returned as a Long which is correct, but when synced to other databases it is returned as a Double. 

That's expected behavior. The JSON format doesn't distinguish between integer and floating-point; it just has a single "number" type. It's up to the parser code how that's converted to a platform data type.  Sounds like the JSON parser used by Java parses all JSON numbers to Doubles. If you want the number in some other form, you'll need to cast it.

(In case you're worried about round-off error: double-precision floating point can exactly represent all integers up to about ±2^50.)

—Jens

[James Norman]

Thanks for the quick response.  I have a workaround in place now.  The issue is that the serialization/deserialization of the object to Map may get either a long or a double depending where the data came from, while it's always written as double type.  I'm not exactly sure how other numbers will behave, integers seem to stay as integers etc.

The approach is to promote all primitive number types to double then cast back to their respective type.