[
https://issues.apache.org/jira/browse/AVRO-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664380#comment-16664380
]
ASF GitHub Bot commented on AVRO-2248:
--------------------------------------
cutting commented on issue #356: AVRO-2248 Added support for Java parameterized
types
URL: https://github.com/apache/avro/pull/356#issuecomment-433230868
Adding a new fundamental type of schema is incompatible. In particular, any
implementation that has not implemented this will be unable to read data that
uses this feature. Inclusion of this would thus force a major release of Avro,
i.e., 2.0.
Also, does this correspond to a natural language feature in all or most of
the languages where Avro is implemented? For those that it does not, how
should it appear? Related, in Java, tests and examples using Generic and
Specific data would be useful. How is a parameterized type's data represented
in Json? We should not add a fundamental type that's only really supported by
Java's ReflectData.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Added support for Java parameterised types with ReflectData in Avro
> -------------------------------------------------------------------
>
> Key: AVRO-2248
> URL: https://issues.apache.org/jira/browse/AVRO-2248
> Project: Avro
> Issue Type: Improvement
> Components: java
> Affects Versions: 1.8.2
> Reporter: Vamsi Subhash Achanta
> Priority: Major
> Labels: pull-request-available
>
> Hi all,
> Avro doesn't have support for Parameterised types currently. Ex:
> class Pair<K,V> {
> K key;
> V value;
> }
> For the above class, the schema generation fails when using ReflectData and
> ReflectDatumWriter. This is because the type information is not handled
> within the avro code and is not passed over.
> For Map/Collection, it is explictly hardcoded and supported within the code
> but for other generic types, it is not. The fix is modelled on how Map is
> solved internally and generalises it for all generic type parameters.
> The fix (and patch attached) addresses this by adding a new type called PARAM
> (like MAP) and is handled in all places including:
> * schema generation using ReflectData..getSchema(..
> * schema parsing using Schema.Parser
> * serialization to bytes using ReflectDatumWriter
> * de-serialization from bytes to object using ReflectDatumReader
> The test for the above cases is included in the patch and we have tested it
> with ~15 level nested type param schemas in our codebase internally here. The
> current code works for our cases. We are open to fixing bugs that might arise
> out of this if any.
> Please help us mainline this into avro code as it can be a very useful
> feature to all. Thanks a lot for the great project!
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
