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

Zoltan Farkas commented on AVRO-1810:
-------------------------------------

I hit this issue when serializing a SpecificRecord (generated from idl) with a 
GenericDatumWriter.

Everything works fine when serializing withe SpecificDatumWriter, but since all 
generated avro records implement GenericRecord I don't see why they should not 
be serializable with a GenericDatumWriter...

I see 2 ways to fix this:

1) make GenericDatumWriter handle java enums.
2) make the generated enums (like Reuben suggested) implement GenericEnumSymbol.

I used approach 1 to fix my fork.

I am not sure the separation between GenericRecord and SpecificRecords 
reader/writers is ideal...

For example I wrote some utilities to on the fly generate Generic Data like:

https://github.com/zolyfarkas/spf4j/blob/master/spf4j-avro/src/main/java/org/spf4j/avro/GenericRecordBuilder.java

how to use:

https://github.com/zolyfarkas/spf4j/blob/master/spf4j-avro/src/test/java/org/spf4j/avro/GenericRecordBuilderTest.java

This is still beta quality, but the results are slightly more efficient (10%) 
GenericRecord implementations. (see JMH benchmark: 
https://github.com/zolyfarkas/spf4j/blob/master/spf4j-benchmarks/src/test/java/org/spf4j/avro/GenericRecordBenchmark.java)



> 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)

Reply via email to