search

atlasmap-attic / atlasmap-runtime

AtlasMap runtime engine and design time services
http://atlasmap.io
Other
3 stars 8 forks source link

[DISCUSS] JO-2 BigInteger and BigDecimal support #11

Open mattrpav opened 7 years ago

mattrpav commented 7 years ago

Possible use cases:

Modeling BigInteger/BigDecimal is complicated in that many formats don't support the concept of a dynamically sized number. For Xml and Json, we may need to consider converting them to a string if they exceed 64 bit integer size.

id Mapping Supported mapping Notes
BIG-1 BigInteger -> BigInteger Java-to-Java only?
BIG-2 BigInteger -> BigDecimal Java-to-Java only?
BIG-3 BigDecimal -> BigInteger Java-to-Java only?
BIG-4 BigDecimal -> BigDecimal Java-to-Java only?
BIG-5 other number -> BigInteger x-to-Java only?
BIG-6 other non-number -> BigInteger x-to-Java only?
BIG-7 other number -> BigDecimal x-to-Java only?
BIG-8 other non-number -> BigDecimal x-to-Java only?
BIG-9 BigInteger -> other number Java-to-x only? Range check?
BIG-10 BigInteger -> other non-number Java-to-x only? Convert to string?
BIG-11 BigDecimal -> other number Java-to-x only? Range check?
BIG-12 BigDecimal -> other non-number Java-to-x only? Convert to string?
igarashitm commented 7 years ago

Note: JSON schema doesn't have precision limit on a number

number
An arbitrary-precision, base-10 decimal number value, from the JSON "number" production

Maybe we need to override JSON parser and take it as a string anyway.

chirino commented 7 years ago

The Big* java variants would b able to handle any precision. But unless we have to deal with the value as a number in the mapper (math functions?), perhaps treating it as a string is best.