Ryan Blue created AVRO-1469:
-------------------------------
Summary: Support interchangeable object models
Key: AVRO-1469
URL: https://issues.apache.org/jira/browse/AVRO-1469
Project: Avro
Issue Type: New Feature
Components: java
Affects Versions: 1.7.6
Reporter: Ryan Blue
The current way to use a different in-memory representation is to subclass one
of the data modules, like {{GenericData}}, and override the relevant methods.
This approach has a couple of drawbacks:
1. Because Reflect inherits from Generic, both must be subclassed and altered
to preserve the choice between generic records and POJOs. This may have nothing
to do with the object classes being changed (e.g., Map implementation).
2. Replacing the data class tends to also require replacing the DatumReader and
DatumWriter implementation.
>From discussion on a related Kite issue, Doug writes:
bq. It's hard to know up front what bundles of functionality folks will need.
We might add a separate interface that determines the representation of each
type (records, maps, arrays, enums, strings, bytes, fixed, unions, numbers,
etc.), then have generic/specific/reflect implementations for records,
collection/array implementations for array, Utf8/String for string,
tagged/untagged unions, etc. Currently we have one big interface (GenericData)
for all of these, with a hierarchy of implementations that provide a few common
combinations, but far fewer than are logically possible.
The use case I'd like to focus on is interchanging both the POJO/record model
and the other objects independently. I think this follows from the distinction
between Generic and Reflect and is a good starting point.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
