[
https://issues.apache.org/jira/browse/AVRO-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthew McMahon updated AVRO-2837:
----------------------------------
Attachment: AVRO-2837.patch
> Java DecimalConversion handling of scale and precision
> ------------------------------------------------------
>
> Key: AVRO-2837
> URL: https://issues.apache.org/jira/browse/AVRO-2837
> Project: Apache Avro
> Issue Type: Improvement
> Components: java, logical types
> Affects Versions: 1.8.2, 1.9.2
> Reporter: Matthew McMahon
> Priority: Major
> Attachments: AVRO-2837.patch
>
>
> Came across an interesting issue in Avro 1.8.2
> Configured a decimal logical type (Fixed type of size 12 with scale of 15 and
> precision of 28).
> Due to an upstream bug, a value of 1070464558597365250.000000000000000
> (1.07046455859736525E+18 that is then rescaled to 15) appears, and the
> DecimalConversion attempts to turn it into a Fixed type.
> This should have failed, as it has a precision of 34 and won't fit into the
> 12 bytes (needs 14). However in 1.8.2 this still writes a value that
> downstream processing then works out is invalid and errors.
> Basically the top 2 bytes are thrown away.
> This problem is fixed in 1.9.2 due to the change in
> https://issues.apache.org/jira/browse/AVRO-2309 as this particular issue
> fails when it attempts to pass an offset of -2 to the System.arraycopy method.
> That seems ok, but is a bit of a red herring to the actual issue.
> Proposing a couple changes to the DecimalConversion:
> * Check precision set on the decimal logical type. If value has greater
> precision then error with more informative message
> * Still check scale and error if value has a greater scale. However if the
> scale in value is less, than it seems safe to update the scale and pad zero's
> rather than error
> * Do this for both Bytes and Fixed types
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
