SEPURI-SAI-KRISHNA opened a new pull request, #12996:
URL: https://github.com/apache/seatunnel/pull/12996
Yes, contributing to Apache SeaTunnel.
Closes #12995.
## What this fixes
`SqlWhereConditionHelper` has two guards that stop the JDBC source
auto-adding `where_condition` columns to SQL where that would change the
query's meaning. Both uppercase the user's SQL with the JVM default locale
before matching keyword literals, so under a Turkish or Azerbaijani locale
every guard keyword containing an `i` stops matching and the guard is bypassed.
`toUpperCase()` maps `i` to `İ` (U+0130) there, so `union` becomes `UNİON` and
never matches `UNION`.
Measured through the real public entry point, which is what `ChunkSplitter`
calls:
```text
input : select id from a union select id from b
en-US : SELECT * FROM (select id from a union select id from b) tmp WHERE
name = 'x'
tr-TR : SELECT * FROM (select id , name from a union select id from b) tmp
WHERE name = 'x'
```
`name` is added to the first branch only, so the branches no longer have
equal arity and the database rejects the statement. The `DISTINCT` case is
worse because it does not fail: `select distinct id , name from t` is distinct
over two columns instead of one, so the job silently returns a different row
count.
Seven distinct keywords are affected (`UNION`, `UNION ALL`, `INTERSECT`,
`MINUS`, `DISTINCT`, `HAVING`, `LIMIT`, `WITH`). `EXCEPT`, `GROUP BY`, `OFFSET`
and `OVER` contain no `i` and are unaffected, which is why the breakage is
partial.
## The change
All seven bare `toUpperCase()` calls in the class are pinned to
`Locale.ROOT`. They all match SQL keywords rather than producing user-facing
text, so a fixed locale is correct for every one of them.
Four have a measured consequence: `:174` and `:338` are the two guards, and
`:278`/`:280` fail to strip a leading `DISTINCT`/`ALL` from the column list,
which is the second half of the `DISTINCT` damage. The remaining three (`:240`,
`:505`, `:566`) only match keywords containing no `i` (`SELECT`, `FROM`, `AND`,
`OR`, `NOT`, `NULL`, `TRUE`, `FALSE`), so they are inert today. I pinned them
anyway rather than leave three instances of the same defect in one class for
the next keyword to reactivate, and I am happy to narrow it to the four if a
reviewer prefers the smaller diff.
This follows the approach already merged for the same defect class in the
Zeta SQL transform, #12495 and #12618, which both settled on `Locale.ROOT`.
No behaviour changes on any locale whose uppercasing of ASCII is the usual
one, so there is no incompatible change to document. No new dependency, no
config change, no public API change.
## Tests
Two methods added to the existing `SqlWhereConditionHelperTest`, driven
under `tr-TR` and `az-AZ`:
- `testSqlStructureGuardsAreIndependentOfTheDefaultLocale` asserts both
guards still fire for all twelve keyword forms, including the four unaffected
ones as controls.
- `testApplyWhereConditionWithWrapIsIndependentOfTheDefaultLocale` asserts
the emitted SQL is byte-identical to the `Locale.ROOT` result, which pins the
user-visible consequence rather than a helper's boolean.
Both snapshot and restore the base locale plus the `FORMAT` and `DISPLAY`
category defaults, restoring the base first because setting it overwrites both
categories.
Validated locally:
- `./mvnw spotless:check -pl seatunnel-connectors-v2/connector-jdbc` passes.
- `SqlWhereConditionHelperTest`: 120 tests, 0 failures.
- Full module: `Tests run: 1125, Failures: 0, Errors: 4, Skipped: 6`. All
four errors are Testcontainers `startContainer` failures in the Oracle and
Kingbase container tests, caused by `permission denied ...
/var/run/docker.sock` on my machine. None of those classes reference this code.
- Mutation checked: reverting the seven pins to bare `toUpperCase()` fails
exactly the two new tests and nothing else, with
`expected: <...(select id from a union select id from b)...> but was:
<...(select id , name from a union select id from b)...>`.
Restoring them returns 120 of 120.
--
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]
