[
https://issues.apache.org/jira/browse/AVRO-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17369516#comment-17369516
]
Artur Kalimullin commented on AVRO-3164:
----------------------------------------
I understand the problem now.
The problem was that even though SpecificDatumReader was used, underneath it
was using GenericDatumReader which eventually called put(int field$,
java.lang.Object value$) which contained code like case 0: amount =
(java.math.BigDecimal)value$; break;
Casting didn't work there because put() was called with a String (which is
actually expected).
However, everything works properly when using custom coder which is disabled by
default. After setting system property
org.apache.avro.specific.use_custom_coders to true, everything works as
expected.
So the question is, should the behaviour of put() in compiled classes be
changed to calling constructor with a String?
instead of case 0: amount = (java.math.BigDecimal)value$; break; something like
case 0: amount = new java.math.BigDecimal(value$.toString()); break; (with
exception handling for the URL and URI of course)
> Allow stringable types deserialization if java-class is specified
> -----------------------------------------------------------------
>
> Key: AVRO-3164
> URL: https://issues.apache.org/jira/browse/AVRO-3164
> Project: Apache Avro
> Issue Type: New Feature
> Components: java
> Reporter: Artur Kalimullin
> Priority: Major
>
> Currently, compiler supports java-class and generates java classes with the
> given class. It works properly with serialization as toString() is being
> called, however, on deserialization compiler generates casting instead of
> calling a constructor with the string argument.
> It works with the ReflectData but not with the SpecificData which throws
> ClassCastException in runtime.
> To solve this, the same behaviour as ReflectData could be used (calling a
> constructor with a String argument)
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
