[
https://issues.apache.org/jira/browse/AVRO-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting updated AVRO-1449:
-------------------------------
Attachment: AVRO-1449.patch
Here's a patch that implements this. The current test suite tests it some, but
we should probably add more tests. I also patched a few schemas that it found
to be in error.
The validity checking itself is straightforward. Enabling and disabling it is
not.
Doing it at parse time isn't good enough, since schemas are often created
directly with the Schema API (e.g., IDL & builder). So the check needs to be
in the Field constructor. But then to be able to turn checking on and off we
need a global flag (yuk) that the constructor reads.
The existing name validation uses a ThreadLocal<Boolean> as such a global flag.
Schema.Parser sets this around calls to parse(). By default name validation
is on and is disabled when parsing schemas from data files.
For default values, we want validation off by default. I used the same
ThreadLocal mechanism to permit Schema.Parser to enable or disable it. As with
name validation, I added no mechanism to enable checking outside of
Schema.Parser.
However I think we should do something by default to let folks know there's a
problem with their schema. Throwing an exception would break lots of existing
users. Logging a warning might be appropriate. The avro core module however
doesn't currently have a logging dependency, and we shouldn't add one here. So
this patch prints warnings to System.err. Does that seem reasonable?
> 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
>
>
> 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)
