[
https://issues.apache.org/jira/browse/AVRO-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182574#comment-17182574
]
Micah Kornfield commented on AVRO-2918:
---------------------------------------
You should potentially raise this on the dev@ mailing list to gain visibility.
I don't have much standing in the community, but it seems like this might add
more complexity than the cost of implementation. It seems like most of the
benefits could be gained via composition, but it is quite possible I'm not
fully understanding the problem this is trying o solve.
It would also need to potentially deal with odd edge cases for field name
collisions.
> Schema polymorphism
> -------------------
>
> Key: AVRO-2918
> URL: https://issues.apache.org/jira/browse/AVRO-2918
> Project: Apache Avro
> Issue Type: New Feature
> Components: logical types, misc, spec
> Reporter: Jonathan Rapoport
> Priority: Critical
> Labels: features
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> Include the option to use named types as base types for a new schema. Allow
> for MRO generation. Field inheritance.
> The benefits of this approach include:
> * Defining a schema as validation for a certain wire, and so allowing the
> receiver to be certain of the structure of the data (this works today).
> However, defining an extension of this schema, or certain schemas which can
> be normalized to the original schema, but contain additional information,
> will not allow it to be sent over the same wire.
> * Backwards compatibility through inheritance - you never break the old
> schema, thus allowing a long integration period, with no need to recode all
> processes familiar with the schema. The new schema will simply inherit the
> old one, and only add information.
> * Allow for full data control through polymorphism, and the ability to
> replace structures within any supported language.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
