[
https://issues.apache.org/jira/browse/AVRO-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16950995#comment-16950995
]
Werner Daehn commented on AVRO-2592:
------------------------------------
I leave that decision up to you, regarding priority. Personally, I find it
extremely dangerous and unexpected. And although the workaround is simple and
requires to be very careful about the methods being called in what order (or
have an extra rewind everywhere), I'd argue the solution is equally simple to
implement.
The point I do not know is why the ByteBuffer.position was used in first place.
Am I correct with the statement "The ByteBuffer does wrap one Datum only and
always?". In my opinion, the ByteBuffer position handling is neat for cases
where you have one very large buffer and you append data. Even better, in cases
where a cyclic buffer is required and you flip its contents.
Look at it from my point of view, the user. I had a code that sometimes gave me
the Zero-length-BigInt error and sometimes not. Could not find a reason. Input
data was the same, test case also. What was the root cause? In a debug
statement I did convert the Decimal to a String as part of the logging content,
that did move the position and caused above problem.
Based on this input what would you suggest?
> Avro decimal fails on certain conditions - ByteBuffer.position() is the root
> cause
> ----------------------------------------------------------------------------------
>
> Key: AVRO-2592
> URL: https://issues.apache.org/jira/browse/AVRO-2592
> Project: Apache Avro
> Issue Type: Bug
> Components: java
> Affects Versions: 1.9.1
> Reporter: Werner Daehn
> Priority: Blocker
>
> The Decimal Conversion from/to Bytebuffer is using the methods that consider
> the current position, e.g. remaining().
> [https://github.com/apache/avro/blob/release-1.9.1/lang/java/avro/src/main/java/org/apache/avro/Conversions.java#L82]
> At first sight that looks like a good idea. But actually it creates all sorts
> of problems.
> For example this code fails with "Zero Length BigInteger":
>
> {code:java}
> BigDecimal d = BigDecimal.valueOf(3.1415); BigDecimal d =
> BigDecimal.valueOf(3.1415);
> Decimal decimaltype = LogicalTypes.decimal(7, 4); ByteBuffer buffer =
> DECIMAL_CONVERTER.toBytes(d, null, decimaltype);
> System.out.println(DECIMAL_CONVERTER.fromBytes(buffer, null,
> decimaltype).toString());
> BigDecimal n = DECIMAL_CONVERTER.fromBytes(buffer, null, decimaltype);
> System.out.println(n.toString());{code}
>
> Reason is obvious. The first call to fromBytes() moves the position from 0 to
> the last byte. The second invocation reads from the last position, hence zero
> records.
> There are other situations this might cause issues, e.g. a user might create
> the ByteBuffer via other means and it is normal that the position is after
> the last byte. Then the serialization would not work either. And many other.
> As the ByteBuffer is used to wrap a single BigDecimal, I would suggest to
> remove all position-aware/setting methods and read/write from position zero.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
