Uploaded image for project: 'Apache Avro'
  1. Apache Avro
  2. AVRO-951

Records with field named "data" collide with new builder code from specific compiler

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Blocker
    • Resolution: Fixed
    • 1.6.0
    • 1.6.1
    • java
    • None

    Description

      When I updated my dependencies from 1.5.x to 1.6.0 I found that one of my generated specific data classes failed to compile. The schema definition is:

        record DataResponse {
          string queryId;
          int startRow;
          boolean more;
          array<array<union {IRI, BNode, PlainLiteral, TypedLiteral, 
                             string, boolean, int, long, float, double,
                             null} >> data;
        }
      

      which I'm using to create:

      {
          "type" : "record",
          "name" : "DataResponse",
          "fields" : [ {
            "name" : "queryId",
            "type" : "string"
          }, {
            "name" : "startRow",
            "type" : "int"
          }, {
            "name" : "more",
            "type" : "boolean"
          }, {
            "name" : "data",
            "type" : {
              "type" : "array",
              "items" : {
                "type" : "array",
                "items" : [ "IRI", "BNode", "PlainLiteral", "TypedLiteral", "string", "boolean", "int", "long", "float", "double", "null" ]
              }
            }
          }
      

      which generates this code in the specific compiler:

        public static class Builder extends org.apache.avro.specific.SpecificRecordBuilderBase<DataResponse>
          implements org.apache.avro.data.RecordBuilder<DataResponse> {
      
          private java.lang.CharSequence queryId;
          private int startRow;
          private boolean more;
          // *** local field named "data"
          private java.util.List<java.util.List<java.lang.Object>> data;    
      
         // snipped some
          
          /** Creates a Builder by copying an existing DataResponse instance */
          private Builder(sherpa.protocol.DataResponse other) {
                  super(sherpa.protocol.DataResponse.SCHEMA$);
            if (isValidValue(fields[0], other.queryId)) {
              // *** Call intended to go to super class data field
              queryId = (java.lang.CharSequence) data.deepCopy(fields[0].schema(), other.queryId);
              fieldSetFlags[0] = true;
            }
            if (isValidValue(fields[1], other.startRow)) {
              startRow = (java.lang.Integer) data.deepCopy(fields[1].schema(), other.startRow);
              fieldSetFlags[1] = true;
            }
            if (isValidValue(fields[2], other.more)) {
              more = (java.lang.Boolean) data.deepCopy(fields[2].schema(), other.more);
              fieldSetFlags[2] = true;
            }
            if (isValidValue(fields[3], other.data)) {
              data = (java.util.List<java.util.List<java.lang.Object>>) data.deepCopy(fields[3].schema(), other.data);
              fieldSetFlags[3] = true;
            }
          }
      

      If you note the two ***'ed comments above, the first is the locally generated "data" field. The second is a reference to a super-class's field, also named data (although it's shadowed by the local data field). The super class is org.apache.avro.data.RecordBuilderBase.

      Seems like any of the protected fields at that point could potentially collide with actual record field names ("schema", "fields", "fieldSetFlags" would all have the same problem). Maybe if those fields were accessed via getters in the generated code, the local fields could shadow the super class without issue.

      Attachments

        1. AVRO-951.patch
          26 kB
          James Baldassari
        2. AVRO-951.patch
          15 kB
          Doug Cutting

        Issue Links

          Activity

            People

              cutting Doug Cutting
              puredanger Alex Miller
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: