You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by "Zezeng Wang (Jira)" <ji...@apache.org> on 2019/11/26 08:20:00 UTC
[jira] [Commented] (AVRO-2401) Initializing decimal fields with
fixed fields can cause padding issues in Java
[ https://issues.apache.org/jira/browse/AVRO-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16982246#comment-16982246 ]
Zezeng Wang commented on AVRO-2401:
-----------------------------------
I think this is a decimal padding problem.
If the fixed size is greater than the length of the byte,
it is caused by zero padding at the end of the copy,
and the value returned by the signum function of BigDecimal should be used to fill the first offset byte
> Initializing decimal fields with fixed fields can cause padding issues in Java
> ------------------------------------------------------------------------------
>
> Key: AVRO-2401
> URL: https://issues.apache.org/jira/browse/AVRO-2401
> Project: Apache Avro
> Issue Type: Bug
> Components: java
> Reporter: Gray
> Priority: Minor
> Attachments: DecimalConverterTest.java
>
>
> I'm having a hard time figuring out if this a a bug or expected behavior. If we initialize a decimal field with a fixed logical type that has fewer bytes then the fixed size has, then the bytes get padded on the right with 0s. This changes their resulting decimal value. I think they should be padded from the left. The spec is vague here so I'm not sure if this is a bug or just unexpected outcome.
> I've attached my junit test. The result of the test is: AssertionError: expected:<660.51> but was:<169090.56>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)