[jira] [Created] (AVRO-2372) Compiler can gerade breaking code when there are cross-namespace type references
Benjamin Zikarsky created AVRO-2372:
---
Summary: Compiler can gerade breaking code when there are
cross-namespace type references
Key: AVRO-2372
URL: https://issues.apache.org/jira/browse/AVRO-2372
Project: Apache Avro
Issue Type: Bug
Components: java
Affects Versions: 1.9.0
Reporter: Benjamin Zikarsky
*Problem*
With the current version of 1.9.0-SNAPSHOT (as of 9th of April 2019) the java
compiler generates broken code under 2 circumstances:
# Type A (e.g. {{foo.A}}) references Type B from a different namespace (e.g.
{{bar.B}})
# Both types fulfill the criteria of {{SpecificCompiler.isCustomCodable(..)}}
This generates code where {{foo.A}} is generated with a {{protected
customCode(...)}} which calls out to {{bar.B}}'s {{protected customCode(...)}}.
This breaks as {{A}} cannot access {{B}}'s protected methods.
*Possible solutions*
# Change the {{isCustomCodeable}} criteria in such a way that it fails for
namespace-crossing type-references
# Open up access to customCode/customDecode. This may expose internals though.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AVRO-2372) Compiler can generate breaking code when there are cross-namespace type references
[
https://issues.apache.org/jira/browse/AVRO-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Zikarsky updated AVRO-2372:
Summary: Compiler can generate breaking code when there are cross-namespace
type references (was: Compiler can gerade breaking code when there are
cross-namespace type references)
> Compiler can generate breaking code when there are cross-namespace type
> references
> --
>
> Key: AVRO-2372
> URL: https://issues.apache.org/jira/browse/AVRO-2372
> Project: Apache Avro
> Issue Type: Bug
> Components: java
>Affects Versions: 1.9.0
>Reporter: Benjamin Zikarsky
>Priority: Major
>
> *Problem*
> With the current version of 1.9.0-SNAPSHOT (as of 9th of April 2019) the java
> compiler generates broken code under 2 circumstances:
> # Type A (e.g. {{foo.A}}) references Type B from a different namespace (e.g.
> {{bar.B}})
> # Both types fulfill the criteria of {{SpecificCompiler.isCustomCodable(..)}}
> This generates code where {{foo.A}} is generated with a {{protected
> customCode(...)}} which calls out to {{bar.B}}'s {{protected
> customCode(...)}}. This breaks as {{A}} cannot access {{B}}'s protected
> methods.
> *Possible solutions*
> # Change the {{isCustomCodeable}} criteria in such a way that it fails for
> namespace-crossing type-references
> # Open up access to customCode/customDecode. This may expose internals though.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Feature freeze Apache Avro 1.9
Hi Ivan,
Thanks for the input. Personally, I'm not using the UUID at all. Any
comments on it Ryan? Since it isn't introduced in any release, we could
remove it if there is a consensus if it doesn't add any value to the Avro
format.
Apart from that, I did some testing last week on some internal projects,
and it went surprisingly well. I would like to proceed into cutting a first
RC.
Cheers, Fokko
Op di 2 apr. 2019 om 03:49 schreef Ivan Greene :
> Somehow only now after I sent this last message did I realize the
> conversion can already be controlled by adding the LogicalType to
> ReflectData as in TestReflectLogicalTypes.java :) So never mind on that
> second part.
>
> However it's worth making a consideration about whether we are interested
> in revising the UUID logicalType to be 16-byte fixed rather than a 36-byte
> string before it is documented in this release.
>
> -- Ivan
>
> On Mon, Apr 1, 2019 at 8:30 PM Ivan Greene
> wrote:
>
> > Another outstanding bit for the release in my mind is the state of the
> > UUID logicalType. As Ryan commented here:
> >
> https://issues.apache.org/jira/browse/AVRO-2021?focusedCommentId=16242524&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16242524
> > there is currently an implemented logical type of 'uuid', however it uses
> > the naive toString/fromString rather than a more compact 16-byte fixed. I
> > think we should think about whether we really need this logical type as
> it
> > doesn't provide much benefit as it is. What do you think?
> >
> > Related is UUID support for ReflectData, which is currently nil (we
> cannot
> > even annotate @Stringable; UUID has no String constructor). Basically the
> > only option for using UUIDs in ReflectData is the user implementing their
> > own CustomEncoding. A long unanswered query on another Jira is here:
> >
> https://issues.apache.org/jira/browse/AVRO-1497?focusedCommentId=16283656&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16283656
> > We could either:
> > - Provide CustomEncoding implementation(s), such as UUIDAsStringEncoding
> > and/or UUIDAsFixedEncoding
> > - Add support for LogicalTypes in ReflectData definitions, through a new
> > annotation a la @AvroLogicalType("timestamp-millis"), etc. where we can
> use
> > the uuid logicalType if we decide to keep that in
> >
> > Taking a look at the history it seems as though LogicalTypes and
> > CustomEncodings share some of the same intentions. It's not clear what
> the
> > better option is in this case. CustomEncoding predates LogicalType by a
> few
> > years, but CustomEncoding is more Java-centric.
> >
> > Please let me know what the thoughts are. I should have some time to work
> > on what we decide on this week. Would like to get these items in for 1.9.
> >
> > -- Ivan
> >
>
[jira] [Created] (AVRO-2373) Remove Empty Package 'ipc'
David Mollitor created AVRO-2373: Summary: Remove Empty Package 'ipc' Key: AVRO-2373 URL: https://issues.apache.org/jira/browse/AVRO-2373 Project: Apache Avro Issue Type: Improvement Components: java Affects Versions: 1.9.0 Reporter: David Mollitor https://github.com/apache/avro/tree/master/lang/java/avro/src/main/java/org/apache/avro/ipc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Feature freeze Apache Avro 1.9
Just to clarify, the UUID logical type was included in 1.8.2 (and perhaps a
release prior to that?), it was just undocumented. So I think one option could
be providing a conversion both to/from string and to/from 16-length fixed,
similar to the way that the decimal type provides conversion to/from fixed as
well as to/from bytes, which can be chosen by the user.
—Ivan
> On Apr 9, 2019, at 9:02 AM, Driesprong, Fokko wrote:
>
> Hi Ivan,
>
> Thanks for the input. Personally, I'm not using the UUID at all. Any
> comments on it Ryan? Since it isn't introduced in any release, we could
> remove it if there is a consensus if it doesn't add any value to the Avro
> format.
>
> Apart from that, I did some testing last week on some internal projects,
> and it went surprisingly well. I would like to proceed into cutting a first
> RC.
>
> Cheers, Fokko
>
> Op di 2 apr. 2019 om 03:49 schreef Ivan Greene :
>
>> Somehow only now after I sent this last message did I realize the
>> conversion can already be controlled by adding the LogicalType to
>> ReflectData as in TestReflectLogicalTypes.java :) So never mind on that
>> second part.
>>
>> However it's worth making a consideration about whether we are interested
>> in revising the UUID logicalType to be 16-byte fixed rather than a 36-byte
>> string before it is documented in this release.
>>
>> -- Ivan
>>
>> On Mon, Apr 1, 2019 at 8:30 PM Ivan Greene
>> wrote:
>>
>>> Another outstanding bit for the release in my mind is the state of the
>>> UUID logicalType. As Ryan commented here:
>>>
>> https://issues.apache.org/jira/browse/AVRO-2021?focusedCommentId=16242524&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16242524
>>> there is currently an implemented logical type of 'uuid', however it uses
>>> the naive toString/fromString rather than a more compact 16-byte fixed. I
>>> think we should think about whether we really need this logical type as
>> it
>>> doesn't provide much benefit as it is. What do you think?
>>>
>>> Related is UUID support for ReflectData, which is currently nil (we
>> cannot
>>> even annotate @Stringable; UUID has no String constructor). Basically the
>>> only option for using UUIDs in ReflectData is the user implementing their
>>> own CustomEncoding. A long unanswered query on another Jira is here:
>>>
>> https://issues.apache.org/jira/browse/AVRO-1497?focusedCommentId=16283656&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16283656
>>> We could either:
>>> - Provide CustomEncoding implementation(s), such as UUIDAsStringEncoding
>>> and/or UUIDAsFixedEncoding
>>> - Add support for LogicalTypes in ReflectData definitions, through a new
>>> annotation a la @AvroLogicalType("timestamp-millis"), etc. where we can
>> use
>>> the uuid logicalType if we decide to keep that in
>>>
>>> Taking a look at the history it seems as though LogicalTypes and
>>> CustomEncodings share some of the same intentions. It's not clear what
>> the
>>> better option is in this case. CustomEncoding predates LogicalType by a
>> few
>>> years, but CustomEncoding is more Java-centric.
>>>
>>> Please let me know what the thoughts are. I should have some time to work
>>> on what we decide on this week. Would like to get these items in for 1.9.
>>>
>>> -- Ivan
>>>
>>
[jira] [Created] (AVRO-2374) Remove hardcoded Jackson versions from tests
Fokko Driesprong created AVRO-2374: -- Summary: Remove hardcoded Jackson versions from tests Key: AVRO-2374 URL: https://issues.apache.org/jira/browse/AVRO-2374 Project: Apache Avro Issue Type: Improvement Affects Versions: 1.8.2 Reporter: Fokko Driesprong Assignee: Fokko Driesprong Fix For: 1.9.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AVRO-2373) Remove Empty Package 'ipc'
[ https://issues.apache.org/jira/browse/AVRO-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Mollitor updated AVRO-2373: - Fix Version/s: 1.9.0 > Remove Empty Package 'ipc' > -- > > Key: AVRO-2373 > URL: https://issues.apache.org/jira/browse/AVRO-2373 > Project: Apache Avro > Issue Type: Improvement > Components: java >Affects Versions: 1.9.0 >Reporter: David Mollitor >Priority: Minor > Fix For: 1.9.0 > > > https://github.com/apache/avro/tree/master/lang/java/avro/src/main/java/org/apache/avro/ipc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AVRO-2373) Remove Empty Package 'ipc'
[ https://issues.apache.org/jira/browse/AVRO-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16813685#comment-16813685 ] ASF subversion and git services commented on AVRO-2373: --- Commit 350a3f0beb779c783daecf6f1b1de58e53e5f3fa in avro's branch refs/heads/master from Daniel Kulp [ https://gitbox.apache.org/repos/asf?p=avro.git;h=350a3f0 ] [AVRO-2373] Move package.html for ipc from avro to ipc jar > Remove Empty Package 'ipc' > -- > > Key: AVRO-2373 > URL: https://issues.apache.org/jira/browse/AVRO-2373 > Project: Apache Avro > Issue Type: Improvement > Components: java >Affects Versions: 1.9.0 >Reporter: David Mollitor >Priority: Minor > Fix For: 1.9.0 > > > https://github.com/apache/avro/tree/master/lang/java/avro/src/main/java/org/apache/avro/ipc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (AVRO-2373) Remove Empty Package 'ipc'
[ https://issues.apache.org/jira/browse/AVRO-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved AVRO-2373. --- Resolution: Fixed Assignee: Daniel Kulp > Remove Empty Package 'ipc' > -- > > Key: AVRO-2373 > URL: https://issues.apache.org/jira/browse/AVRO-2373 > Project: Apache Avro > Issue Type: Improvement > Components: java >Affects Versions: 1.9.0 >Reporter: David Mollitor >Assignee: Daniel Kulp >Priority: Minor > Fix For: 1.9.0 > > > https://github.com/apache/avro/tree/master/lang/java/avro/src/main/java/org/apache/avro/ipc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AVRO-2373) Remove Empty Package 'ipc'
[ https://issues.apache.org/jira/browse/AVRO-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16813711#comment-16813711 ] Hudson commented on AVRO-2373: -- SUCCESS: Integrated in Jenkins build AvroJava #648 (See [https://builds.apache.org/job/AvroJava/648/]) [AVRO-2373] Move package.html for ipc from avro to ipc jar (dkulp: [https://github.com/apache/avro/commit/350a3f0beb779c783daecf6f1b1de58e53e5f3fa]) * (add) lang/java/ipc/src/main/java/org/apache/avro/ipc/package.html * (delete) lang/java/avro/src/main/java/org/apache/avro/ipc/package.html > Remove Empty Package 'ipc' > -- > > Key: AVRO-2373 > URL: https://issues.apache.org/jira/browse/AVRO-2373 > Project: Apache Avro > Issue Type: Improvement > Components: java >Affects Versions: 1.9.0 >Reporter: David Mollitor >Assignee: Daniel Kulp >Priority: Minor > Fix For: 1.9.0 > > > https://github.com/apache/avro/tree/master/lang/java/avro/src/main/java/org/apache/avro/ipc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
