[
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)