avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bridger Howell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AVRO-1810) GenericDatumWriter broken with Enum
Date Thu, 14 Sep 2017 19:19:00 GMT

    [ https://issues.apache.org/jira/browse/AVRO-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16166847#comment-16166847
] 

Bridger Howell commented on AVRO-1810:
--------------------------------------

No particular use case, I was just looking at the way that {{GenericData.EnumSymbol}} supports
being compared with any other {{GenericEnumSymbol}} and wondering if there was a good reason
for that.

Considering that {{equals}} is final for enums, it seems harder to keep that property (although
{{compareTo}} should be fine because the type signatures for {{java.lang.Enum}}'s {{compareTo}}
only matches the enum type, not {{GenericEnumSymbol}}?).

At least It would be nice to avoid weird cases where the following test fails:
{noformat}
/* assuming SpecificEnum is generated from enumSchema */
final SpecificEnum specificSymbol = SpecificEnum.FOO;
final GenericData.EnumSymbol genericSymbol = new GenericData.EnumSymbol(enumSchema, "FOO");

assertTrue(genericSymbol.equals(specificSymbol) == specificSymbol.equals(genericSymbol));
{noformat}

> GenericDatumWriter broken with Enum
> -----------------------------------
>
>                 Key: AVRO-1810
>                 URL: https://issues.apache.org/jira/browse/AVRO-1810
>             Project: Avro
>          Issue Type: Bug
>          Components: java
>    Affects Versions: 1.8.0
>            Reporter: Ryon Day
>            Priority: Blocker
>             Fix For: 1.9.0, 1.8.4
>
>
> {panel:title=Description|titleBGColor=#3FA|bgColor=#DDD}
> Using the GenericDatumWriter with either Generic OR SpecificRecord will break if an Enum
is present.
> {panel}
> {panel:title=Steps To Reproduce|titleBGColor=#8DB|bgColor=#DDD}
> I have been tracking Avro decoding oddities for a while.
> The tests for this issue can be found [here|https://github.com/ryonday/avroDecodingHelp/blob/master/src/test/java/com/ryonday/test/Avro180EnumFail.java]
> {panel}
> {panel:title=Notes|titleBGColor=#3AF|bgColor=#DDD}
> Due to the debacle that is the Avro "UTF8" object, we have been avoiding it by using
the following scheme:
> * Write incoming records to a byte array using the GenericDatumWriter
> * Read back the byte array to our compiled Java domain objects using a SpecificDatumWriter
> This worked great with Avro 1.7.7, and this is a binary-incompatable breaking change
with 1.8.0.
> This would appear to be caused by an addition in the {{GenericDatumWriter:163-164}}:
> {code}
>   if (!data.isEnum(datum))
>       throw new AvroTypeException("Not an enum: "+datum);
> {code}
> {panel}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message