[
https://issues.apache.org/jira/browse/AVRO-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899468#action_12899468
]
John Kristian commented on AVRO-617:
------------------------------------
From: Doug Cutting <[email protected]>
Date: Mon, 16 Aug 2010 13:53:55 -0700
To: <[email protected]>
Subject: Re: field union default (in Java)
Defaults can be ambiguous. For example, {"a":1} as the default value for a
union of a record with a field named "a" of type int and a map with long
values, or "foo" for the default value of a union of string, bytes and an enum.
If you switched the order in the union, you'd get no warning.
However we could do a better job of detecting some erroneous default values
earlier. The resolver currently handles default values in
ResolvingGrammarGenerator#encode(). We could add more checks there. For
example, the NULL case there could throw an exception if the JSON node n is
non-null. Similarly, the INT case should throw an exception if JSON node is
non-numeric (currently it calls n.getIntValue() which, unfortunately returns
zero for non-numeric nodes).
> Catch mismatched default values
> -------------------------------
>
> Key: AVRO-617
> URL: https://issues.apache.org/jira/browse/AVRO-617
> Project: Avro
> Issue Type: Improvement
> Components: java
> Affects Versions: 1.3.3
> Reporter: John Kristian
>
> Please signal an error when a field's default value isn't permitted; that is
> when it doesn't match the field type. In particular, when the type is a
> union, please signal an error if the default isn't a permitted value of the
> first schema in the union.
> For example, these field declarations are erroneous:
> {"name":"f1", "type":["null", "int"], "default": 3}
> {"name":"f2", "type":["int", "null"], "default": null}
> In the current Java implementation, schema resolution using these schemata
> will result in f1=null (not 3) and f2=0 (not null). This quiet choice of an
> unintended value is apt to cause trouble that's difficult to diagnose.
> I propose that schema parsing signal an error when attempting to parse such
> an erroneous schema. Another option is for schema resolution to signal an
> error when the reader's schema is erroneous. Schema parsing is better, I
> think, since it will help catch mistakes earlier, when they're cheaper to
> correct. It wouldn't hurt for both schema parsing and resolution to check.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
