[
https://issues.apache.org/jira/browse/AVRO-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914946#comment-13914946
]
Ryan Blue commented on AVRO-1469:
---------------------------------
One solution is related to AVRO-1468, proposed by Doug:
bq. One might build a data model with something like,
bq. dataModel = new GenericData().setRecordModel(new ReflectRecordModel());
bq. We might be lazy about abstracting models. We might start by adding just
RecordModel and see if that, combined with the existing hierarchy, satisfies
most needs. When someone needs a bundle not possible with that, then we can
incrementally add models for more types. So we'd start by implementing
GenericRecordModel, SpecificRecordModel, ReflectRecordModel and change
GenericData to delegate all record-related work to its RecordModel field.
> 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)
