avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Justin SB (JIRA)" <j...@apache.org>
Subject [jira] Updated: (AVRO-228) Refactor to separate concerns: (de)serialization vs marshalling to data model
Date Fri, 20 Nov 2009 06:31:40 GMT

     [ https://issues.apache.org/jira/browse/AVRO-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Justin SB updated AVRO-228:

    Attachment: 0001-Separated-serialization-code-from-marshalling-code.patch


> Refactor to separate concerns: (de)serialization vs marshalling to data model
> -----------------------------------------------------------------------------
>                 Key: AVRO-228
>                 URL: https://issues.apache.org/jira/browse/AVRO-228
>             Project: Avro
>          Issue Type: Improvement
>          Components: java
>    Affects Versions: 1.3.0
>            Reporter: Justin SB
>         Attachments: 0001-Separated-serialization-code-from-marshalling-code.patch
> I've attached a patch that separates out the code that deals with marshalling to java
data models (Generic, Specific, Reflect) from the code that deals with (de)serializtion (DatumReader,
DatumWriter).  This means that e.g GenericDatumReader, SpecificDatumReader and ReflectDatumReader
are unnecessary.  Instead, a single AvroDatumReader is parameterized with a ClassMapping.
 The class mapping interface is currently implemented by the existing GenericData, SpecificData,
ReflectData mappers.
> The patch is large, so might be quite hard to follow.  Essentially I renamed GenericDatumReader
to AvroDatumReader, and moved any model-specific functionality to the ClassMapping interface.
 I did the same for DatumWriter & Requestor & Responder.
> There remains some oddities for the ProxyingResponder / Requestor, but I wanted to keep
the patch as a straight re-organization without significant code changes.
> I believe this patch will set us up for some refactors down the road - ClassMapping is
really 3 interfaces in one - the mapping of Java types to Avro types, some utility functions
(like hashCode), and field accessors.  Splitting this interface into 3 interfaces would allow
reuse of the parts separately.  Then it would be easy to use avro with arbitrary data models
(by implementing the accessor functions) without needing to implement DatumWriters etc.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message