ziggythehamster opened a new issue #10983:
URL: https://github.com/apache/druid/issues/10983
### Description
Currently, the SQL JSON interface will return decimals as e.g., `{"foo":
1.2345}`. Client libraries which don't know to handle this as a decimal value
instead of a float value would then coerce this to a float, and potentially
cause a loss of precision. This appears to be a relatively simple change to
allow the client to control the Jackson JsonGenerator.Feature
WRITE_BIGDECIMAL_AS_PLAIN, but I'm not 100% sure that decimals are BigDecimal
inside Druid. The other option, to make all numbers strings, is not appropriate
because you wouldn't want to have to convert whole numbers or floats from
strings back into their native types.
### Motivation
- I'm working on a Ruby client library
- Wrapping all decimal calculations in `CAST(x AS VARCHAR)` is boilerplate
- The Avatica API already handles this correctly by passing type
information, but the Avatica API is not documented with enough detail that it
would be feasible for a non-Calcite developer to write an Avatica client in an
unsupported language. FFI + the Go version might be an option, but that seems
like a whole lot more work than dealing with this simple JSON API.
- This API does not pass type information, which means that an approach of
converting anything that has a decimal point into a precision-preserving format
(BigDecimal in Ruby) wastes resources unnecessarily. A generic client library
could ship a decimal string to a user without loss of precision or performance,
and then the user, who knows the data types, could convert as needed.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
