rwzdk opened a new pull request, #13012:
URL: https://github.com/apache/seatunnel/pull/13012
I confirm that I am contributing to Apache SeaTunnel.
## Background
Part of `SqlWhereConditionHelper` uppercases the SQL text and then keeps
using the index found while scanning the **original** string.
`String.toUpperCase()` is not length-preserving: in Java, `'ß'` expands to
`"SS"`, and several other code points (`fi`, `ı̇`, ÿ, ...) also change length
when uppercased. Once that happens, every index derived from the uppercased
string points one or more characters off in the real SQL.
Issue: #12998
### Reproduction
```java
SqlWhereConditionHelper.applyWhereConditionWithWrap("select id as maß from
t", "name = 'x'", true);
```
Before the change the wrapper produced a mangled projection instead of
appending the missing field before the main `FROM` clause:
```
expected: <SELECT * FROM (select id as maß , name from t) tmp WHERE name =
'x'>
but was: <SELECT * FROM (select name,id as maß from t) tmp WHERE name =
'x'>
```
`findMainFromClauseIndex` compared `upperSql.startsWith("FROM", i)` while
`i` came from scanning the original string, so with `'ß'` the `FROM` keyword
was never recognized (its uppercase index is one position later), and
`findColumnListRange` had the same defect for `SELECT`. A JDBC source whose
projection or alias contains such a character therefore gets its SQL rewritten
incorrectly.
## What is changed
Match keywords **case-insensitively on the original string** with
`String.regionMatches(true, index, "FROM", 0, 4)` (and the `SELECT` equivalent)
instead of comparing against an uppercased copy. Indices then always refer to
the text that is sliced afterwards, so no case-expansion drift is possible. The
uppercased local variable in `findMainFromClauseIndex` becomes unnecessary and
is removed.
No config option, default value, public API or SPI contract changes;
behavior for pure-ASCII SQL is byte-identical.
## Testing
Five unit tests added to the existing `SqlWhereConditionHelperTest` (no new
test class): `FROM` detection with a case-expanding alias, wildcard detection,
the two wrap/insertion paths, and an ASCII control asserting the unicode alias
yields exactly the same output shape.
```
mvn -pl seatunnel-connectors-v2/connector-jdbc
-Dtest=SqlWhereConditionHelperTest -DfailIfNoTests=false test
```
Before the fix: `Tests run: 123, Failures: 4` (all four are the new
case-expansion cases).
After the fix: `Tests run: 123, Failures: 0, Errors: 0, Skipped: 0` / `BUILD
SUCCESS`.
One note on the local toolchain: `mvn spotless:apply` cannot run on this
machine because the pinned `spotless-maven-plugin:2.29.0` calls
`JCImport.getQualifiedIdentifier()`, which was removed in JDK 21
(`InvocationTargetException` from the plugin, unrelated to this diff). The
added lines were hand-formatted to the surrounding Google/AOSP style, every
added line is within 100 columns, and `git diff` contains no formatting-only
churn on untouched lines. Please let CI confirm the spotless gate, or point me
at the JDK you want the plugin run under and I will re-push.
Prepared with an AI coding agent.
--
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]
