On Mon, Jan 20, 2014 at 3:50 AM, Alparslan Avcı
<alparslan.a...@agmlab.com> wrote:
> {"name": "field1", "type": ["null", {"type":"map", "values":["null",
> "string"]}],"default":null}
>
> can be represented as like
>
> {"name": "field1", "type": {"type":"map", "values":"string",
> "nullable":true}, "nullable":true, "default":null}You'd like an alternate syntax for expressing nullability, is that right? The semantics would be the same, a value could either be of the named type or it could be null, right? The original design was done this way because, once we had unions and a null type, it seemed better to compose these two concepts than to invent another equivalent concept. (Would the above two schemas be equal? Probably not. Would they express exactly the same datatypes? Probably.) See also this talk (made after Avro was designed): http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare But, whether we like it or not, that design decision is now past. We cannot easily make such a change in the JSON schema language since it would create compatibility problems. For example, a data file generated using the new syntax could not be read by code that had not yet been upgraded to process this syntax. Existing code would not know that "nullable" is a special property and would fail in strange ways, since it would expect to find items of the specified type, not union values. We can devise higher-level schema languages that are translated into Avro schemas and that handle nullability differently. So you could define a pre-processor for JSON schemas that converted them from the above syntax into Avro's standard syntax, and use this when interacting with Avro. > Null types in unions will always cause an exceptional situation since they > are not 'types' at all. I don't understand this statement. Doug
