[
https://issues.apache.org/jira/browse/AVRO-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17372788#comment-17372788
]
Ryan Skraba commented on AVRO-3164:
-----------------------------------
Thanks for this investigation -- I read through your pull request a bit late,
but I think I see the problem!
Do you think the record's generated put should be detecting whether the
incoming data is a String or a BigDecimal (for example) and accepting it in
either case?
As a community, we haven't been really *great* with keeping up with the
experimental flags once they're proposed and implemented. I have no objection
to switching the default for custom coders. Ideally, they would be behaving in
the same way, but it's interesting to see that this bug doesn't exist there.
> 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)
