Grokbase Groups Avro user May 2013
FAQ
It would be nice to be able to reference an existing class when using the
specific compiler.

If you have an existing "com.mycompany.Foo" enum (or SpecificRecord, or
Fixed type), then provide the specific compiler with the type prior to
parsing the schema, it could accept a reference:

{"type":"record", "name":"com.mycompany.Rec", "fields": [
   {"name":"fooField", "type":"com.mycompany.Foo"}
]}

Ordinarily, this would fail to compile, but given a reference to an existing
compatible type, such as an enum, it could work.

-Scott
On 5/9/13 4:39 PM, "Felix GV" wrote:

Hello,

I'm currently writing an avro schema which includes an enum field that I
already have as a java enum in my application.

At first, I named the avro field with the same fully qualified name (package
name dot enum name) as my existing java enum. I then ran the avro compiler and
found that it overwrote my existing java enum with an avro-generated enum.

I find this slightly annoying because my java enum had comments documenting
the purpose of each enum value, and the avro-generated enum doesn't have this.

I see two or three potential solutions:
1. Accepting to replace my current enum with the avro-generated one in my code
base, which I feel I cannot document properly (since I have access to just one
doc attribute for the whole enum, instead of per symbol). On a side note, I
haven't found any way to have a multi-line doc attribute in an avro schema, so
that makes things slightly more annoying still. I wouldn't mind settling on
using the avro-generated enums without documentation per symbol if at least I
could have one big doc/comment that documents all symbols at once, but since
it seems the doc attribute must be a one-liner, this is starting to be a
little too messy for my taste...
2. Maintaining two separate enums: my manually written (and documented) enum
as well as the avro-generated enum. For now, I think this is what I'm going to
do, because those enums have little chances of changing anyway, but from a
maintenance standpoint, it seems pretty horrendous...
3. I guess there's a third way, which would involve creating a script that
backs up my enums, compiles all my schemas, and then restores my backed up
enums, but this also seems ultra messy :( ... I haven't tested if it'd work
(since the manually written enum is missing the $SCHEMA field), but I guess it
would...
Am I being OCD about this? or is this a concern that others have bumped into?
How do you guys deal with this? Did I miss anything in the way avro works?

P.S.: I've seen that reflect mappings may be able to work with arbitrary java
enums, but since they seemed discouraged for performance reasons, I haven't
digged much in this direction. I'd like to keep using .avsc files if possible,
but if there's a better way, I can certainly try it.

P.P.S.: We're currently using avro 1.6.1, but if the latest version provides a
nice way of handling my use case, then I guess I could get us to upgrade...

Thanks a lot :) !

--
Felix

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 6 | next ›
Discussion Overview
groupuser @
categoriesavro
postedMay 9, '13 at 11:40p
activeMay 16, '13 at 11:52p
posts6
users4
websiteavro.apache.org
irc#avro

People

Translate

site design / logo © 2021 Grokbase