Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.4.0-incubating
-
Component/s: None
-
Labels:None
-
Flags:Patch
Description
When sending for example
{"type":"NUMBER","value":"333.333"}
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 was working just by accident.
The attached patch 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.
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
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.
Agreed, stay as close as possible to the SQL type system. I get confused about NUMBER vs NUMERIC, so you may be right.
Fixed in http://git-wip-us.apache.org/repos/asf/incubator-calcite/commit/efecdade.
Thanks for the patch, Lukas!
Resolved in release 1.4.0-incubating (2015-08-23)
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.