avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Blue (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AVRO-1469) Support interchangeable object models
Date Thu, 27 Feb 2014 19:31:20 GMT

    [ 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
> 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
> 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

View raw message