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
