avro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Cameron <peter.came...@2icworld.com>
Subject ReflectDatumReader and Writer classes
Date Thu, 05 Jul 2012 16:44:57 GMT
I'm a bit confused of the "status" of the ReflectDatumReader and 
ReflectDatumWriter classes. We use them to transparently serialise and 
deserialise JavaBeans-like objects. We automatically get an instance of 
the expected class back and do not need to write any conditional code 
based on what the schema is. Perfect in our Java world, and just what 
reflection is for.

Now if I look at the package doc for org.apache.avro.reflect I see this:

"This API is not recommended except as a stepping stone for systems that 
currently uses Java interfaces to define RPC protocols. For new RPC 
systems, the |specific| 
<http://avro.apache.org/docs/1.7.0/api/java/org/apache/avro/specific/package-summary.html>

API is preferred. For systems that process dynamic data, the |generic| 
<http://avro.apache.org/docs/1.7.0/api/java/org/apache/avro/generic/package-summary.html>

API is probably best."

What I'm confused by is the assertion that the generic API is "probably 
best" for processing dynamic data.

However, I can see no automatic, transparent way of using the generic 
readers and writers to serialise a JavaBean and then deserialise the 
stream into an instance of that JavaBean -- automatically. Writing 
conditional code and playing around with field names is not an answer.

Am I missing something, or should your assertion be weakened?

Peter


Mime
View raw message