You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by "Doug Cutting (JIRA)" <ji...@apache.org> on 2014/02/27 20:17:20 UTC
[jira] [Commented] (AVRO-1468) implement interface-based
code-generation
[ https://issues.apache.org/jira/browse/AVRO-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914919#comment-13914919 ]
Doug Cutting commented on AVRO-1468:
------------------------------------
This should be implemented as new functionality that applications must explicitly switch to. For example, POM files must be updated to specify the new-format code generation, and runtime code must then also be updated to adapt to API changes in the generated code. Since it is opt-in, this can thus be considered a compatible addition and included in a minor, bugfix release.
This also thus provides the (rare) opportunity to make incompatible changes to generated code. In particular, the generated implementations can be immutable, use java.lang.String for string schemas, not have a visible SCHEMA$ member nor public fields, etc.
> implement interface-based code-generation
> -----------------------------------------
>
> Key: AVRO-1468
> URL: https://issues.apache.org/jira/browse/AVRO-1468
> Project: Avro
> Issue Type: New Feature
> Reporter: Doug Cutting
>
> The current specific compiler generates a concrete class per record. Instead, we might generate an interface per record that might be implemented in different ways. Implementations might include:
> - A wrapper for a generic record. This would permit the schema that is compiled against to differ from that of the runtime instance. A field that was added since code-generation could be retained as records are filtered or sorted and re-written.
> - A concrete record. This would be similar to the existing specific.
> - A wrapped POJO. The generated class could wrap a POJO using reflection. Aliases could map between the schema used at compilation and that of the POJO, so field and class names need not match exactly. This would permit one to evolve from a POJO-based Avro application to using generated code without breaking existing code.
> This approach was first described in http://s.apache.org/AvroFlex
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)