You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CirceJsonDeserializer.deserialize uses JsonBigDecimal in all numeric cases.
In my use case, it'd be nice to have JsonLong instead of JsonBigDecimal when the value can fit into Long range (-9223372036854775808 - 9223372036854775807).
A flag/configuration field could also be introduced to specify whether deserialization should pick strictest type or vice versa.
The text was updated successfully, but these errors were encountered:
This sounds like a reasonable optimization, but I don't see any reason for it to be configurable, since users should never rely on the JsonNumber representation.
Without this optimization, users need to check whether the value of JsonBigDecimal could fit into a long or not at each downstream app, if their case depends on type check, e.g. json schema validation
Configurability was a side idea, I don't have strong arguments there
CirceJsonDeserializer.deserialize
usesJsonBigDecimal
in all numeric cases.In my use case, it'd be nice to have JsonLong instead of JsonBigDecimal when the value can fit into Long range (-9223372036854775808 - 9223372036854775807).
A flag/configuration field could also be introduced to specify whether deserialization should pick strictest type or vice versa.
The text was updated successfully, but these errors were encountered: