[
https://issues.apache.org/jira/browse/AVRO-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14496597#comment-14496597
]
Ryan Blue commented on AVRO-1568:
---------------------------------
Here's an example: say you have a 3rd party geo library for shapes. A shape has
some internal representation, but also an envelope (think bounding box) that is
probably calculated and stored. So Shape looks like roughly like this API:
{code:java}
class Shape:
static Shape fromBytes(byte[] bytes)
byte[] getShapeAsBytes()
float getMinX()
float getMinY()
float getLength()
float getWidth()
{code}
Because you don't control the implementation for Shape or its subclasses,
Polygon and Path, you don't know what you're going to get when you reflect
their fields. I'm arguing that it is much more reliable to serialize Shape
using its public API. That way, you can use its compact representation accessed
through {{getShapeAsBytes}} and store information relevant for generic use, its
bounding box. Those might be derived values in the implementations, plus the
internal fields can change in ways that aren't compatible with Avro's schema
evolution rules. Using the public API instead of reflection is, I think, a
better choice.
> Allow Java polymorphism in Avro for third-party code
> ----------------------------------------------------
>
> Key: AVRO-1568
> URL: https://issues.apache.org/jira/browse/AVRO-1568
> Project: Avro
> Issue Type: Improvement
> Affects Versions: 1.7.6
> Reporter: Sachin Goyal
>
> A large number of Java designs interacting with databases with
> Hibernate/Couchbase (perhaps, even otherwise) have Java polymorphism of the
> form:
> {code:java}
> class Base
> {
> Integer a = 5;
> }
> class Derived extends Base
> {
> String b = "Foo";
> }
> class PolymorphicDO
> {
> Base b = new Derived();
> }
> {code}
> Jackson handles this kind of field by using annotations such as:
> {code}
> @JsonTypeInfo(use = JsonTypeInfo.Id.CLASS, include =
> JsonTypeInfo.As.PROPERTY, property = "@class”)
> {code}
> If such a thing can be added to Avro, all those Java designs could become
> immediately usable with Avro. They would also become Hadoop compatible due to
> AvroSerde.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
