Avro
  1. Avro
  2. AVRO-1468

implement interface-based code-generation

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      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

        Issue Links

          Activity

          Hide
          Keegan Witt added a comment -

          Would the ability to do polymorphic interface references like this be out of the scope of this Jira?

          {
            "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"},
            ]
          }
          
          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());
              }
            }
          }
          
          Show
          Keegan Witt added a comment - Would the ability to do polymorphic interface references like this be out of the scope of this Jira? { "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 " }, ] } 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()); } } }
          Hide
          Doug Cutting added a comment -

          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.

          Show
          Doug Cutting added a comment - 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.

            People

            • Assignee:
              Unassigned
              Reporter:
              Doug Cutting
            • Votes:
              2 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:

                Development