[ 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.