[
https://issues.apache.org/jira/browse/AVRO-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830467#action_12830467
]
Philip Zeyliger commented on AVRO-404:
--------------------------------------
I think I know what Todd is talking about here, so I'll do an example.
We might have a record X. One user might want to annotate it with "java-class:
org.foo.X". Another user might want to also use the reflection API, but
annotate it with "org.bar.X". Since X has been defined externally (in some
other project, say), nobody really wants to fork X, both 'foo' and 'bar' users
merely want to add some mix-ins. They could certainly do so at runtime, but
then the schema is this weird "mixed-mode" thing. That's the reflect API
example. The specific API example happens when we end up having options about
how we generate the generated code, and different users want different options.
I think we might be able to make this more of a "genavro"/(avroidl?) issue
rather than a schema issue. Support some sort of modification of existing
schemas after inclusion...
> Support "mixin properties" for specific codegen
> -----------------------------------------------
>
> Key: AVRO-404
> URL: https://issues.apache.org/jira/browse/AVRO-404
> Project: Avro
> Issue Type: New Feature
> Components: java, spec
> Reporter: Todd Lipcon
>
> As we add more features for RPC and the specific codegen, there are some
> codegen options that should be provided as annotations on schema fields. For
> example, some users may want to turn binary fields into byte[], and other
> people may prefer ByteBuffer. Since these are codegen-scoped and not
> data-scoped, it would be nice to allow the properties to be "mixed in" at
> codegen time. By moving them out of the main schema definition, different
> users of the same Avro protocol could make different choices for the codegen
> in their specific applications.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.