Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Avro >> mail # user >> Why is the String type a Schema property?


Copy link to this message
-
Re: Why is the String type a Schema property?
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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB