[
https://issues.apache.org/jira/browse/CALCITE-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14624026#comment-14624026
]
Lukas Lalinsky commented on CALCITE-795:
----------------------------------------
Sorry, opened a pull request a forgot to link it here.
https://github.com/apache/incubator-calcite/pull/105
Regarding the Java/SQL data types, that's a bit complicated. As I was browsing
the code, I have noticed that there are many data type definitions in Avatica.
For example, in the remote server, clients get one set of type names in the
"columns" signature and another in the "parameters" signature. I think it would
be best to use the SQL type names everywhere, which would mean using `NUMERIC`
instead of `NUMBER` and `NUMERIC` implies a decimal number with exact precision.
> Precision loss wen sending a decimal number via the remote JSON service
> -----------------------------------------------------------------------
>
> Key: CALCITE-795
> URL: https://issues.apache.org/jira/browse/CALCITE-795
> Project: Calcite
> Issue Type: Bug
> Reporter: Lukas Lalinsky
> Assignee: Julian Hyde
>
> When sending for example {code}{"type":"NUMBER","value":"333.333"}{code} to
> the "fetch" request of the remote JSON service, the exact value will not be
> kept and after one UPSERT/SELECT roundtrip in Phoenix I will get 333.332 back.
> Interestingly enough, this worked in Calcite 1.2 before the TypedValue class
> was introduced, but I think that working just by accident.
> The attached patch changes changes the Jackson object mapper to decode any
> JSON float to BigDecimal, unless the code explicitly asks for Float/Double. I
> think that shouldn't break anything and it solves this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
