[
https://issues.apache.org/jira/browse/CALCITE-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14624019#comment-14624019
]
Julian Hyde commented on CALCITE-795:
-------------------------------------
Did you forget to attach a patch?
The behavior you want sounds correct, but we should not specify Avatica's
behavior in terms of Java bindings, rather in terms of the SQL type system.
JSON's handling of numeric values is complicated, but the goal is that the
value gets from client to server and back to client and every bit of the value
is preserved. That probably means transmitting exact numbers as exact and FP
numbers as FP.
> 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)
