jmullins opened a new pull request #739:
URL: https://github.com/apache/avro/pull/739
Validation of numeric default values in Java is incorrect and results
in API inconsistencies. Consider the following examples:
Double values as int field default values:
public void testDoubleAsIntDefaultValue() {
Schema.Field field = new Schema.Field("myField",
Schema.create(Schema.Type.INT), "doc", 1.1);
field.hasDefaultValue(); // true
field.defaultValue(); // internal DoubleNode (1.1)
field.defaultVal(); // null
GenericData.get().getDefaultValue(field); // Integer (1)
field = new Schema.Field("myField",
Schema.create(Schema.Type.INT), "doc", 1.0);
field.hasDefaultValue(); // true
field.defaultValue(); // internal DoubleNode (1.0)
field.defaultVal(); // null
GenericData.get().getDefaultValue(field); // Integer (1)
}
Invalid long value as int field default value:
public void testInvalidLongAsIntDefault() {
Schema.Field field = new Schema.Field("myField",
Schema.create(Schema.Type.INT), "doc", Integer.MAX_VALUE + 1L);
field.hasDefaultValue(); // true
field.defaultValue(); // internal LongNode (2147483648)
field.defaultVal(); // Long (2147483648)
GenericData.get().getDefaultValue(field); // Integer (-2147483648)
}
This PR makes changes to invalidate incorrect default values for INT and
LONG schemas, including all floating point values, e.g. 1.0.
Additionally it contains changes to try and return the appropriate
Object type given the schema type.
This change is necessary for correctness and consitency but also
because users cannot disable default value validation and handle
these cases on their own since the underlying Field.defaultValue()
is no longer public. Users only have access to default values
mutated by Field.defaultVal() and GenericData.getDefaultValue().
Notes on JacksonUtils.toObject():
- This method is used to convert the underlying JsonNode default value
to an Object when Field.defaultVal() is called. This method is
invoked regardless of whether default value validation is true or
false.
- For LongNode values we continue to return Long values for INT
schemas in the case we cannot safely convert to an Integer.
This behavior, while maintained, is inconsistent with that
of FloatNode / DoubleNode where null is returned for INT
and LONG schemas. Additional changes may be needed for
further consistency.
Make sure you have checked _all_ steps below.
### Jira
- [ ] My PR addresses the following [Avro
Jira](https://issues.apache.org/jira/browse/AVRO/) issues and references them
in the PR title. For example, "AVRO-1234: My Avro PR"
- https://issues.apache.org/jira/browse/AVRO-XXX
- In case you are adding a dependency, check if the license complies with
the [ASF 3rd Party License
Policy](https://www.apache.org/legal/resolved.html#category-x).
### Tests
- [ ] My PR adds the following unit tests __OR__ does not need testing for
this extremely good reason:
### Commits
- [ ] My commits all reference Jira issues in their subject lines. In
addition, my commits follow the guidelines from "[How to write a good git
commit message](https://chris.beams.io/posts/git-commit/)":
1. Subject is separated from body by a blank line
1. Subject is limited to 50 characters (not including Jira issue reference)
1. Subject does not end with a period
1. Subject uses the imperative mood ("add", not "adding")
1. Body wraps at 72 characters
1. Body explains "what" and "why", not "how"
### Documentation
- [ ] In case of new functionality, my PR adds documentation that describes
how to use it.
- All the public functions and the classes in the PR contain Javadoc that
explain what it does
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
