gharris1727 commented on code in PR #17510:
URL: https://github.com/apache/kafka/pull/17510#discussion_r1817251244
##########
connect/api/src/main/java/org/apache/kafka/connect/data/Values.java:
##########
@@ -1041,6 +1043,10 @@ private static SchemaAndValue parseAsNumber(String
token) {
}
private static SchemaAndValue parseAsExactDecimal(BigDecimal decimal) {
+ BigDecimal abs = decimal.abs();
+ if (abs.compareTo(TOO_BIG) > 0 || (abs.compareTo(TOO_SMALL) < 0 &&
BigDecimal.ZERO.compareTo(abs) != 0)) {
+ throw new NumberFormatException("outside efficient parsing
range");
Review Comment:
At this stage in parsing, we've successfully parsed a BigDecimal. This
method tries to losslessly cast the BigDecimal to a primitive integer type. If
the cast would be lossy, it returns null and lets the caller figure out whether
it's a float32, float64, or has to be an arbitrary precision decimal.
Rather than throwing NumberFormatException and making this a STRING, we
should return null, and let the other fallback logic happen, so this shows up
as an arbitrary precision Decimal.
I also suspect that the comparison could be a little tighter in that case:
TOO_BIG could be LONG_MAX, and TOO_SMALL could be ONE, eliminating calling
setScale for `1e20` which cannot possibly fit in a LONG.
--
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.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
