SEPURI-SAI-KRISHNA commented on code in PR #11937:
URL: https://github.com/apache/seatunnel/pull/11937#discussion_r3842029150
##########
seatunnel-transforms-v2/src/main/java/org/apache/seatunnel/transform/sql/zeta/functions/NumericFunction.java:
##########
@@ -285,23 +307,78 @@ private static Number round(Number v1, Number v2,
RoundingMode roundingMode) {
v1 = t.equals("FLOAT") ? bd.floatValue() :
bd.doubleValue();
break;
}
+ default:
Review Comment:
Fixed in `0a6d6d9d6`, thanks, this was the right catch and I've kept it in
this PR rather than deferring it, since the `default` branch is what turns the
mismatch from silent into fatal.
`t.toUpperCase(Locale.ROOT)` here, and I pinned `convertTo`'s switch the
same way. That second one is **not** reachable today, its labels are
`BYTE`/`INTEGER`/`SHORT`/`LONG`, none of which contains a lowercase `i`, and no
`BigDecimal` reaches it, but leaving one locale-sensitive `toUpperCase` beside
a fixed one is how this comes back.
I confirmed your analysis rather than assuming it, and `BigDecimal` really
is the only label affected: under `Locale("tr","TR")` it maps to `BİGDECİMAL`,
while `Byte`/`Short`/`Integer`/`Long`/`Double`/`Float` are all unchanged,
`Integer`'s only `i` is already the capital.
Regression test is `testRoundingDispatchIsLocaleIndependent`, which sets the
Turkish locale and restores the previous one in a `finally` as you asked. It
asserts the *rounded result* (`ROUND(1.25, 1) == 1.3`, `CEIL(1.25) == 2`)
rather than just "does not throw", so it fails both ways: against the exception
this PR would have introduced, and against the silently-unrounded `1.25` that
`dev` returns today.
Verified: 1102 tests green in `seatunnel-transforms-v2` (1101 before),
`spotless:check` clean. I also reverted *only* this `Locale.ROOT` and re-ran,
exactly one test fails, this one, with no collateral across the other 1101.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
