avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Kristian (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AVRO-617) Catch mismatched default values
Date Tue, 17 Aug 2010 17:02:16 GMT

    [ 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 <cutting@apache.org>
Date: Mon, 16 Aug 2010 13:53:55 -0700
To: <user@avro.apache.org>
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.


Mime
View raw message