Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Avro >> mail # user >> Best practices for java enums...?

Copy link to this message
Re: Best practices for java enums...?
Hi Scott,

How would you envision this working with the avro compiler? Would it be
akin to the capabilites added by
AVRO-1188<https://issues.apache.org/jira/browse/AVRO-1188> where
the existing java enums would be referenced in the importedFiles directory
passed in parameter to the compiler?

Should I file another JIRA for this...?

On Mon, May 13, 2013 at 5:38 PM, Scott Carey <[EMAIL PROTECTED]> wrote:

> 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" <[EMAIL PROTECTED]> 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