avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Baldassari (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AVRO-951) Records with field named "data" collide with new builder code from specific compiler
Date Thu, 03 Nov 2011 23:49:32 GMT

     [ https://issues.apache.org/jira/browse/AVRO-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

James Baldassari updated AVRO-951:
----------------------------------

    Attachment: AVRO-951.patch

Here's a patch.  Let me know if this works.  It renames all protected members in RecordBuilderBase
such that they end in '$'.  I also made the method parameters in the generated classes end
in '$' as you suggested.  I had to modify the checkstyle config to allow variables to be named
this way.  I also renamed RecordBuilderBase#getDefaultValue(Field) to 'defaultValue' to prevent
a potential conflict with the getter for a field named 'defaultValue' or 'default_value'.

I added a field called 'data' to the Social protocol to verify that it would compile with
these changes, and it does.  All unit tests pass.
                
> Records with field named "data" collide with new builder code from specific compiler
> ------------------------------------------------------------------------------------
>
>                 Key: AVRO-951
>                 URL: https://issues.apache.org/jira/browse/AVRO-951
>             Project: Avro
>          Issue Type: Bug
>          Components: java
>    Affects Versions: 1.6.0
>            Reporter: Alex Miller
>            Priority: Blocker
>             Fix For: 1.6.1
>
>         Attachments: AVRO-951.patch
>
>
> 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:
> {code}
>   record DataResponse {
>     string queryId;
>     int startRow;
>     boolean more;
>     array<array<union {IRI, BNode, PlainLiteral, TypedLiteral, 
>                        string, boolean, int, long, float, double,
>                        null} >> data;
>   }
> {code}
> which I'm using to create: 
> {code}
> {
>     "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" ]
>         }
>       }
>     }
> {code}
> which generates this code in the specific compiler: 
> {code}
>   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;
>       }
>     }
> {code}
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message