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 Plain View
Avro >> mail # user >> Primitive type aliases


+
Jay Hacker 2013-04-12, 19:15
+
Doug Cutting 2013-04-12, 21:09
+
Jeremy Kahn 2013-04-12, 21:22
+
Doug Cutting 2013-04-12, 21:35
+
Jay Hacker 2013-04-15, 16:03
Copy link to this message
-
Re: Primitive type aliases
On Mon, Apr 15, 2013 at 9:03 AM, Jay Hacker <[EMAIL PROTECTED]> wrote:
> Right now, I just have an extra metadata key in my field definition of
> "xtype": "date", which I use as my own representation hint.  I feel this
> conveys the intent of the schema much more clearly than an inline record
> would, and is also much more compact.  I'm trying to get rid of even that,
> so I can just say "type": "date".

If you define "date" as a record then you can do that today.  The only
overhead is in the in-memory representation, where a record may be
heavier-weight than desired.  In which case one might optimize this
representation, as I suggested before.

> Would it be difficult to add built-in types to the list of things you can
> alias?  This also does not seem to need a schema language change -- perhaps
> just a spec clarification ;) -- and would yield simpler schemas.

I don't see how this could be implemented compatibly.  Aliases are not
currently referred to in same schema.  They're used to rewrite another
schema's names, to adapt it to the new schema with the aliases.  An
implementation that does not support aliases (like Python) can
currently read schemas that include aliases, since the names in the
aliases are never referred to.  But if we started requiring that
aliases in the current schema are resolved while reading instances of
that schema then implementations that do not support aliases would not
be able to read such schemas.  Since Avro 1.0 we have not changed the
schema language incompatibly and we should not do so lightly.

A representation hint like "inline" would be optional and compatible.

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