[prev in list] [next in list] [prev in thread] [next in thread] 

List:       avro-user
Subject:    Re: Why is the String type a Schema property?
From:       Ey-Chih chow <eychih () gmail ! com>
Date:       2012-05-27 1:58:08
Message-ID: 1E49D2EE-AAB0-47C0-A1ED-DD3F805E58F2 () gmail ! com
[Download RAW message or body]

Under the avro map/reduce framework, if we use the generic representation, how can we \
specify reader's schema?  In addition, what kind of advantages we can get if we use \
the generic representation?  Thanks.

Ey-Chih Chow

On May 24, 2012, at 11:51 AM, Doug Cutting wrote:

> On 05/24/2012 10:28 AM, Mark Hayes wrote:
> > The stored/shared schema must either have these string type properties,
> > or not.  If it does have them, this impacts the string type for all
> > clients reading from the database.  So they would have to all agree on
> > the string type, or dynamically determine it.
> 
> No, there are two schemas involved in reading, the writer's and the reader's.  The \
> reader's schema can determine what string representation is used.  This is the case \
> with reflect and specific, which resolve the schema used when writing against the \
> schema of the class that's being used to represent things when reading.  So you \
> don't need to worry about reflect or specific, since they supply their own schema \
> that has the string representation they expect. 
> So you only need to worry about different string representations if you're using \
> the generic representation and do not specify a distinct reader's schema that you \
> expect to see things as, or if you use some other kind of datum reader (e.g., one \
> you've written yourself) that subclasses GenericDatumReader, doesn't override \
> readString(), and you don't pass an expected, reader's schema. 
> Doug


[prev in list] [next in list] [prev in thread] [next in thread]