[
https://issues.apache.org/jira/browse/AVRO-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14075130#comment-14075130
]
Keegan Witt commented on AVRO-1468:
-----------------------------------
Would the ability to do polymorphic interface references like this be out of
the scope of this Jira?
{code}
{
"type": "record",
"name": "Cat", "namespace":"the.universe",
"fields": [
{"name":"name",
"type":"string"},
{"name":"collarSize",
"type":"int"},
{"name":"aloofness",
"type":"int"},
]
}
{
"type": "record",
"name": "Dog", "namespace":"the.universe",
"fields": [
{"name":"name",
"type":"string"},
{"name":"collarSize",
"type":"int"},
{"name":"friendliness",
"type":"int"},
]
}
{code}
{code}
public interface Pet {
public String getName();
public void setName(String name);
}
public class Cat implements Pet {
// ...
}
public class Dog implements Pet {
// ...
}
public class ExampleUsage {
public static void main(String[] args) {
List<Pet> pets = PetUtil.listPets();
Map<String, Integer> petNames = new HashMap<>();
for (Pet pet : pets) {
petNames.put(pet.getname(), pet.getCollarSize());
}
}
}
{code}
> 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.2#6252)
