[ 
https://issues.apache.org/jira/browse/AVRO-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tom White updated AVRO-1449:
----------------------------

    Attachment: AVRO-1449.patch

Thanks for writing a patch Doug. Overall it looks good. I think logging a 
warning to standard error is reasonable. In the future we could add an option 
to the tools to enforce strict validation of defaults, then in a later release 
make that the default.

Interestingly we don’t have to do anything with schema builder, since the API 
already enforces the constraint. (Nice work Scott!)

{noformat}
… .type().unionOf().stringType().and().nullType().endUnion().nullDefault() // 
fails to compile
… .type().unionOf().nullType().and().stringType().endUnion().nullDefault() // 
works
… .type().optional().stringType() // usual shorthand
{noformat}

There were a couple of small errors in the patch where the validateDefaults 
field wasn't getting set, and VALIDATE_DEFAULTS wasn't being reset to the right 
value. I've attached a new patch fixing that, and also adding a unit test: 
TestSchema already had a test for catching invalid defaults at runtime so I 
extended it to test for parse-time failures when validation is turned on.

> Check default value's type matches union at schema parse time
> -------------------------------------------------------------
>
>                 Key: AVRO-1449
>                 URL: https://issues.apache.org/jira/browse/AVRO-1449
>             Project: Avro
>          Issue Type: Improvement
>          Components: java
>    Affects Versions: 1.7.6
>            Reporter: Tom White
>         Attachments: AVRO-1449.patch, AVRO-1449.patch
>
>
> A common Avro mistake is to declare optional fields as follows:
> {noformat}
> "type": ["string", "null"], "default": null
> {noformat}
> This fails at runtime since the default value's type (null) doesn't match the 
> type of the first type in the union (string). The correct declaration is:
> {noformat}
> "type": ["null", "string"], "default": null
> {noformat}
> Doug 
> [suggested|https://groups.google.com/a/cloudera.org/forum/#!msg/cdk-dev/Xgo5YKEcQ1Q/VkyWP2gnOEMJ]
>  that we throw an exception at schema parse time for cases like this. To 
> ensure backwards compatibility we could make it optional; tools could emit a 
> warning.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Reply via email to