Why don't we just support the Jackson DeserializationOptions? Some
people are going to want BigDecimals instead of floating-point numbers
because they're dealing with monitary values.
Le 1/10/2017 à 6:40 AM, Jacob Barrett a écrit :
On Mon, Jan 9, 2017 at 4:14 PM Darrel Schneider <dschnei...@pivotal.io>
wrote:
Pdx stores and index at the end of the blob so that it can lookup any of
the
fields without reading the preceding fields.
Thanks for that correction.
If you stored every JSON number as a BigDecimal this would mean it would be
stored in PDX as an Object field.
Since PDX allows an Object field to contain any object, instead of always
using BigDecimal you could use a mix of any of the other Number
implementations and still just have one PDX type with an Object field. A
field of "0" could be serialized as a Byte which would end up using 3 bytes
most of the time. BigDecimal is optimized by geode serialization so it
would only take an additional 2 bytes for a field of "0".
After thinking on it some more it makes more sense to me to serialize JSON
number as a PDX double since by spec JS number is 64-bit IEEE 754. The only
problem then is dealing with null values. Maybe it makes sense to fix the
null issue in PDX and allow the supported primitive types to have null
value? This would be nice for replacing the need serialize all object boxed
primitives in Java as PDX Object.
If we don't want to go that far and and null support to the primitives in
PDX then I would suggest serializing JSON number as PDX Object of type
Double for consistency with the precision of JSON/JS.
-Jake
