[jira] [Commented] (AVRO-1810) GenericDatumWriter broken with Enum

["Sean Busbey (JIRA)" <ji...@apache.org>]

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

Sean Busbey commented on AVRO-1810:
-----------------------------------

{quote}
Due to the debacle that is the Avro "UTF8" object, we have been avoiding it by using the following scheme:
{quote}

I am curious to hear what the debacle is, perhaps you could send a description to user@avro or dev@avro?

{quote}
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}
{quote}

This was the breaking change documented in AVRO-997.

The example in {{genericDatumWriter_andSpecificDatumWriter_failForGenericRecord_populatedWithTextualEnum}} is using Strings for enum types. Those should be GenericEnumSymbol, as documented in the [javadocs for type mapping|http://avro.apache.org/docs/1.8.0/api/java/org/apache/avro/generic/package-summary.html] and the release notes for AVRO-997.

The other two examples are based on what look like generated specific classes from [the schemas in your test project|https://github.com/ryonday/avroDecodingHelp/tree/master/src/main/avro], is that right?

If I build the test project at the top level is it straight forward to examine hte generated classes?

> 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
>
> {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.3.4#6332)