You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by "Alex Miller (Created) (JIRA)" <ji...@apache.org> on 2011/11/03 22:15:32 UTC
[jira] [Created] (AVRO-951) Records with field named "data" collide
with new builder code from specific compiler
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
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
[jira] [Commented] (AVRO-951) Records with field named "data"
collide with new builder code from specific compiler
Posted by "James Baldassari (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144219#comment-13144219 ]
James Baldassari commented on AVRO-951:
---------------------------------------
>From a design perspective it's better to use method calls rather than directly accessing the protected members of a superclass, so I support Doug's approach. The only potential drawback is overhead from the extra method invocations. Hopefully the Java compiler will inline those calls or use some other optimization to prevent any performance impact.
> 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
> Assignee: Doug Cutting
> Priority: Blocker
> Fix For: 1.6.1
>
> Attachments: AVRO-951.patch, 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
[jira] [Commented] (AVRO-951) Records with field named "data"
collide with new builder code from specific compiler
Posted by "James Baldassari (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144287#comment-13144287 ]
James Baldassari commented on AVRO-951:
---------------------------------------
Thanks for the clarification, Scott. I don't think subclasses would need to override those methods, so marking them as protected final is probably the way to go.
> 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
> Assignee: Doug Cutting
> Priority: Blocker
> Fix For: 1.6.1
>
> Attachments: AVRO-951.patch, 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
[jira] [Commented] (AVRO-951) Records with field named "data"
collide with new builder code from specific compiler
Posted by "Scott Carey (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144220#comment-13144220 ]
Scott Carey commented on AVRO-951:
----------------------------------
I think we can bend the version rules for this as long as we make it very clear in 1.6.1 release notes that this is an exception to the rule affecting only users of the new builder code generation in the Java implementation.
> 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
> Assignee: Doug Cutting
> Priority: Blocker
> Fix For: 1.6.1
>
> Attachments: AVRO-951.patch, 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
[jira] [Commented] (AVRO-951) Records with field named "data"
collide with new builder code from specific compiler
Posted by "Alex Miller (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144127#comment-13144127 ]
Alex Miller commented on AVRO-951:
----------------------------------
I think it's better from a maintenance point of view to make the fields private and accessible via known methods rather than having protected super class fields.
I'll note that both of these approaches is a breaking change if someone else has a custom extension of RecordBuilderBase that relies on those protected fields. I'm not sure if this class existed before 1.6.0 or if that's a concern.
> 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
> Assignee: Doug Cutting
> Priority: Blocker
> Fix For: 1.6.1
>
> Attachments: AVRO-951.patch, 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
[jira] [Commented] (AVRO-951) Records with field named "data"
collide with new builder code from specific compiler
Posted by "Alex Miller (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13143536#comment-13143536 ]
Alex Miller commented on AVRO-951:
----------------------------------
I should note that the workaround is to not use a field named "data". :)
> 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
>
> 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
[jira] [Updated] (AVRO-951) Records with field named "data" collide
with new builder code from specific compiler
Posted by "Doug Cutting (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Doug Cutting updated AVRO-951:
------------------------------
Assignee: Doug Cutting
Status: Patch Available (was: Open)
> 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
> Assignee: Doug Cutting
> Priority: Blocker
> Fix For: 1.6.1
>
> Attachments: AVRO-951.patch, 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
[jira] [Updated] (AVRO-951) Records with field named "data" collide
with new builder code from specific compiler
Posted by "Doug Cutting (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Doug Cutting updated AVRO-951:
------------------------------
Priority: Blocker (was: Major)
Fix Version/s: 1.6.1
> 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
>
>
> 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
[jira] [Commented] (AVRO-951) Records with field named "data"
collide with new builder code from specific compiler
Posted by "Doug Cutting (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144158#comment-13144158 ]
Doug Cutting commented on AVRO-951:
-----------------------------------
The class did not exist before 1.6.0. It has created a regression against 1.5.x, so I think it's probably fair to change its API in 1.6.1.
> 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
> Assignee: Doug Cutting
> Priority: Blocker
> Fix For: 1.6.1
>
> Attachments: AVRO-951.patch, 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
[jira] [Updated] (AVRO-951) Records with field named "data" collide
with new builder code from specific compiler
Posted by "Doug Cutting (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Doug Cutting updated AVRO-951:
------------------------------
Attachment: AVRO-951.patch
Here's a patch that fixes this by making the field private and using getters without the 'get' prefix, to avoid method name conflicts. It also uses 'this.' when setting fields in generated code to avoid conflict with the parameter named 'other' and renames the 'getDefaultValue' method to be 'defaultValue' to avoid conflict with a generated getter for a field named 'defaultValue'.
> 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, 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
[jira] [Updated] (AVRO-951) Records with field named "data" collide
with new builder code from specific compiler
Posted by "Doug Cutting (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Doug Cutting updated AVRO-951:
------------------------------
Resolution: Fixed
Status: Resolved (was: Patch Available)
I just committed this. I made the accessor methods final.
> 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
> Assignee: Doug Cutting
> Priority: Blocker
> Fix For: 1.6.1
>
> Attachments: AVRO-951.patch, 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
[jira] [Commented] (AVRO-951) Records with field named "data"
collide with new builder code from specific compiler
Posted by "Scott Carey (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144270#comment-13144270 ]
Scott Carey commented on AVRO-951:
----------------------------------
{quote}The only potential drawback is overhead from the extra method invocations. Hopefully the Java compiler will inline those calls or use some other optimization to prevent any performance impact.{quote}
protected methods are eligible to be inlined if there is only one or two implementations 'live' in the JVM. The JVM will deoptimize protected methods that have been inlined if a third implementation is loaded by the classloader. 'protected final' therefore is always eligible to be inlined.
> 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
> Assignee: Doug Cutting
> Priority: Blocker
> Fix For: 1.6.1
>
> Attachments: AVRO-951.patch, 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
[jira] [Commented] (AVRO-951) Records with field named "data"
collide with new builder code from specific compiler
Posted by "Doug Cutting (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13143550#comment-13143550 ]
Doug Cutting commented on AVRO-951:
-----------------------------------
> Maybe if those fields were accessed via getters in the generated code [ ... ]
But then the base class getter couldn't be called getData() as that would conflict with the generated getter. I think it would be better to rename base class fields to include a trailing dollar-sign, e.g., data$. This should also be done for method parameters: 'other' above should be 'other$'.
> 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
> Fix For: 1.6.1
>
>
> 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
[jira] [Commented] (AVRO-951) Records with field named "data"
collide with new builder code from specific compiler
Posted by "Doug Cutting (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AVRO-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144097#comment-13144097 ]
Doug Cutting commented on AVRO-951:
-----------------------------------
Oops. Looks like we both worked on this in parallel and with slightly different approaches. Does anyone have a preference?
> 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
> Assignee: Doug Cutting
> Priority: Blocker
> Fix For: 1.6.1
>
> Attachments: AVRO-951.patch, 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
[jira] [Updated] (AVRO-951) Records with field named "data" collide
with new builder code from specific compiler
Posted by "James Baldassari (Updated) (JIRA)" <ji...@apache.org>.
[ 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