Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

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


Copy link to this message
-
Best practices for java enums...?
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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB