[SEPURI-SAI-KRISHNA]

Yes, glad to contribute to Apache SeaTunnel.

Purpose of this pull request

Fixes #13073.

MySqlCatalog.buildColumn upper cased DATA_TYPE with the JVM default locale. MySQL reports DATA_TYPE in lower case (int, datetime), and under tr-TR and az-AZ i upper cases to İ. So int became İNT, matched no type, and reading the table failed with COMMON-17 unsupported convert type 'İNT'. That breaks a JDBC source with table_path for almost any MySQL table on such a worker. TiDBCatalog extends MySqlCatalog, and OceanBaseMySqlCatalog has the same code.

The case conversions on this path now use Locale.ROOT:

• MySqlCatalog:225 and OceanBaseMySqlCatalog:146, DATA_TYPE. These are the calls that broke real jobs.
• MySqlTypeConverter:199 and OceanBaseMySqlTypeConverter:126. The callers in this repository pass these converters an already upper cased name, but they are public TypeConverters and their own tests call them with lowercase names. In a Turkish JVM, 15 of the existing tests in MySqlTypeConverterTest fail on dev.
• OceanBaseMySqlTypeConverter:304, which parses vector(N). It contains no i, so this one never failed. It is changed so that no default locale conversion is left on the path.
• OceanBaseMySqlCatalog:151 upper cased dataType a second time. That call is removed, since the value is already upper case.

Not changed here:

• The query path. MySQL Connector/J reports getColumnTypeName in upper case (MysqlType.getName()), so it was not affected.
• MySQL CDC. Under a Turkish locale the column types arrive as İNT from Debezium's own DDL parser (ColumnDefinitionParserListener), before SeaTunnel code sees them. That needs a separate change.

Does this PR introduce any user facing change?

Yes, only on workers whose default locale is Turkish or Azerbaijani: MySQL, TiDB and OceanBase (MySQL mode) tables can be read through the catalog there. I compared dev's converters with these on 270 inputs (every MySQL and OceanBase type name in lower, upper and capitalised form, through both converters):

• tr-TR and az-AZ: 106 inputs that failed now convert. No input that converted before gives a different result, and every result now equals the ROOT one.
• ROOT: identical results before and after.

So no working job changes, and no entry in incompatible-changes.md is needed. No option, default or API changed.

How was this patch tested?

Tests, each running under tr-TR and az-AZ and restoring the base locale and the FORMAT and DISPLAY defaults:

• MySqlCatalogUnsignedDetectionTest.shouldReadLowerCaseDataTypeUnderAnyDefaultLocale: buildColumn with DATA_TYPE in lower case, as the server reports it (int, int with int(10) unsigned, datetime). The existing tests in this class mock DATA_TYPE as "INT", which is why they pass in a Turkish JVM.
• MySqlTypeConverterTest.testConvertDoesNotDependOnTheDefaultLocale.
• OceanBaseMySqlTypeConverterTest.testConvertDoesNotDependOnTheDefaultLocale.
• OceanBaseMySqlCatalogTest.shouldReadLowerCaseDataTypeUnderAnyDefaultLocale. This class is new, because no test covered OceanBaseMySqlCatalog. Its constructor does not connect, so it runs offline.

Reverting the four DATA_TYPE calls one at a time, each fails its own test.

I also ran the whole connector-jdbc suite in a JVM started with -Duser.language=tr -Duser.country=TR. With this change, 20 existing tests that failed there pass, all in the MySQL and OceanBase classes, and none starts failing. The ones left are other dialects (DM, SQL Server, YashanDB, IRIS, Xugu, Oracle and others), which I would handle separately, and the field_ide lookup that #13063 fixes.

The existing ITs cover it on a real server too. JdbcMysqlIT.testCatalogReadsColumnTypesUnderTurkishLocale and JdbcOceanBaseMysqlIT.testCatalogReadsColumnTypesUnderTurkishLocale create a table with int, int unsigned, bigint and datetime columns and read it through the catalog under tr-TR and az-AZ. The catalog runs in the test JVM, so that is where the locale is set, and it is restored in finally. I ran both test methods against MySQL 8.0.43 (the IT image) and OceanBase CE 4.4.2.1 (the IT's latest image today). With this change they pass. With the four classes as they are on dev, both fail with COMMON-20 ... {"c_int":"İNT","c_int_unsigned":"İNT","c_bigint":"BİGİNT","c_datetime":"DATETİME"}, and the default locale is restored after the failure.

Checks, JDK 17:

• ./mvnw clean test -pl seatunnel-connectors-v2/connector-jdbc: 1200 tests, 0 failures, 4 errors. The 4 are the Oracle and Kingbase container tests, which need Docker.
• ./mvnw spotless:check -pl seatunnel-connectors-v2/connector-jdbc: clean.
• ./mvnw spotless:check -pl seatunnel-e2e/seatunnel-connector-v2-e2e/connector-jdbc-e2e/connector-jdbc-e2e-part-1,seatunnel-e2e/seatunnel-connector-v2-e2e/connector-jdbc-e2e/connector-jdbc-e2e-part-2: clean.
• ./mvnw -B -T 1 clean test -D"license.skipAddThirdParty"=true -pl seatunnel-ci-tools: 34 tests, 0 failures, 2 skipped by the module.

Open PRs #13070, #12853, #12153, #11971 and #11848 also edit these files. A three-way merge with each is conflict free.

Check list

• Code changed are covered with tests, or it does not need tests for reason
• If any new Jar binary package adding in your PR, please add License Notice according to
  License Notice: none added.
• If necessary, please update the documentation to describe the new feature: not needed, no documented behaviour changes.
• If you are contributing the connector code, please check that the following files are updated:
  1. Update plugin-mapping.properties: not needed, no new connector.
  2. Update the pom file of seatunnel-dist: not needed, no new module.
  3. Add ci label in label-scope-conf: not needed, connector-jdbc is already labelled.
  4. Add e2e test for your connector: extended JdbcMysqlIT and JdbcOceanBaseMysqlIT, see above.
  5. Update connector-v2 doc: not needed, no option or mapping changes.
• Update the release-note: not applicable, the file was removed from dev in [Improve] Remove release-note.md in dev branch #9304.

[DanielLeens]

Thanks for this focused fix! I read the complete eight-file diff and the catalog/dialect callers at 5c29f67137db482a52f8ddbef237e7630aeb4098. The production normalization is correct; one integration-coverage requirement remains.

What Problem Does This PR Solve?

User pain point: MySQL/OceanBase report lowercase type names. Under tr-TR/az-AZ, default-locale uppercasing turns int/datetime into tokens with dotted I, so normal catalog discovery rejects an otherwise supported column.

Fix approach: use Locale.ROOT in both catalogs and both type converters, including OceanBase's vector column-type normalization; remove its now-redundant second uppercase call.

One-sentence summary and example: the same MySQL int unsigned column maps to LONG under Turkish as it already does under English, instead of failing schema discovery.

1. Code Change Review

1.1 Core Logic Analysis

Production locations, all under seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/: catalog/mysql/MySqlCatalog.java:225, catalog/oceanbase/OceanBaseMySqlCatalog.java:146-151, internal/dialect/mysql/MySqlTypeConverter.java:199, and internal/dialect/oceanbase/OceanBaseMySqlTypeConverter.java:126,304.

Before/after:

// before, in catalogs and converters
String dataType = rawType.toUpperCase();
// after
String dataType = rawType.toUpperCase(Locale.ROOT);
// OceanBase: already normalized above, so startsWith("VECTOR") needs no second conversion

Affected complete chain:

JDBC source/sink factory -> selected MySQL/OceanBase catalog
  -> AbstractJdbcCatalog table/column discovery
  -> buildColumn(ResultSet)
     -> read DATA_TYPE, original COLUMN_TYPE, precision/scale/default/nullability
     -> ROOT normalize DATA_TYPE
     -> isNumericUnsignedColumnType(DATA_TYPE, COLUMN_TYPE)
     -> BasicTypeDefine -> corresponding TypeConverter.convert
        -> ROOT normalize -> unsigned/zerofill handling -> existing type switch
        -> PhysicalColumn -> CatalogTable -> source schema / sink preparation
Dialect/TypeMapper and MysqlDataTypeConvertor callers also use the corrected converter.
Reverse DDL conversion and the row writer/checkpoint lifecycle are unchanged.

Key findings: normal discovery reaches the fix; affected locale-specific machine tokens are now stable; raw sourceType/COLUMN_TYPE values remain preserved; vector dimensions and numeric mappings are not redesigned. This is a precise boundary correction, not a global locale workaround. The offline catalogs exercise real buildColumn logic, although their ResultSet values are mocked.

1.2 Compatibility Impact

Fully compatible with the intended supported-type contract. No API, configuration key/default, protocol, serialized schema or checkpoint format changes. Unsigned detection still examines the original column declaration through the existing helper. No migration is required.

1.3 Performance / Side-Effect Analysis

Normalization already occurred during metadata preparation, so CPU, memory and GC complexity do not grow; one redundant conversion is removed. No new network operation, lock, queue, cache, retry, shared production state or resource owner. Per-record idempotence and writer release are unaffected.

1.4 Error Handling and Logging

Unsupported types retain existing contextual errors. There is no added logging or credential exposure. The MySQL test deliberately fails connection acquisition in its override; the new OceanBase catalog constructor only initializes the converter and does not open a connection.

Issue 1: Extend the existing MySQL/OceanBase integration coverage for locale-independent discovery

• Location: seatunnel-connectors-v2/connector-jdbc/src/test/java/org/apache/seatunnel/connectors/seatunnel/jdbc/catalog/mysql/MySqlCatalogUnsignedDetectionTest.java:123; catalog/oceanbase/OceanBaseMySqlCatalogTest.java:45 in the same test source root.
• Problem description: All new coverage is offline. The connector already has JdbcMysqlIT and JdbcOceanBaseMysqlIT, but neither fixture is updated. Mocked DATA_TYPE/COLUMN_TYPE strings do not pin the driver's real metadata-to-job boundary under the affected default locale.
• Potential risk: A future integration-path regression can escape these direct catalog/converter assertions. This is a coverage requirement, not a demonstrated defect in the ROOT changes.
• Best improvement: Add one concise locale-sensitive real catalog/schema assertion to the existing relevant fixtures, preserving unsigned behavior. Apply the locale in the discovery JVM and restore it; do not create a broad duplicate matrix or a new database harness.
• Severity: Medium; blocking coverage requirement.
• Raised by another reviewer: No; retrieved review/inline history contains no existing findings to duplicate.

2. Code Quality Assessment

2.1 Coding Standards

The changes are minimal and use existing Locale imports where available. The new OceanBase test has ASF header/class/method explanation. No new production core method/state field requires a missing contract comment. Existing ENUM/SET/unsigned regression cases remain intact.

2.2 Test Coverage and Test Stability

Stability: Stable in the present sequential JUnit setup. All four additions save/restore base, FORMAT and DISPLAY locales in finally. Fixed input/result assertions cover int, unsigned int and datetime; no sleep, clock, random port, external service or order-sensitive collection assertion. The MySQL test probes no live database, and OceanBase construction does not connect. Enabling parallel JVM-locale tests would require resource coordination. Issue 1 covers the missing IT extension.

The exact-head fork Build and Apache Build are successful; all executed job conclusions are successful. This is CI evidence for the submitted selection, not proof of a non-English live database scenario absent from the diff.

Local evidence: fetched/checked out independent branch seatunnel-review-13076, read all eight changed files plus buildColumn/unsigned/dialect/type-mapper callers with git show/grep; git diff --check passed against merge base f3e1c2ee3b83efd4a1e7fb4cc4fe40b44060c7d0. No local build, test, database, container or runtime execution.

2.3 Documentation Updates

Supported type names, options and defaults remain unchanged. Existing EN/ZH JDBC configuration is still accurate; no new setup/migration recipe is necessary. A brief bug-fix note can mention locale independence without advertising additional types.

3. Architectural Soundness

3.1 Elegance of the Solution

Precise fix. Metadata catalogs and converters own machine-token parsing. Changing JVM-wide defaults would affect unrelated connectors and is not an acceptable substitute.

3.2 Maintainability

Keep the existing switches/unsigned helper and close the small IT gap; no broader catalog refactor is needed.

3.3 Extensibility

The pattern applies to other machine-defined token normalizers; user names and values must retain their own semantics.

3.4 Historical-Version Compatibility

No stored state, option or public method migration. This review does not certify a live rolling-upgrade execution.

4. Issue Summary

Number	Issue	Location	Severity
1	Existing MySQL/OceanBase IT fixtures do not pin the affected locale path	MySqlCatalogUnsignedDetectionTest.java:123; OceanBaseMySqlCatalogTest.java:45	Medium

5. Merge Recommendation

Conclusion: Ready to merge after fixes

1. Blockers — must be fixed
   • Issue 1: add minimal integration coverage, then retain green required CI on the new head.
2. Recommended fixes — non-blocking
   • No unrelated refactor, dependency change or branch-age-only synchronization is requested.

Overall: the production fix is sound and correctly located. Existing fixtures are the smallest safe way to close the coverage requirement. No maintainer approval/change request exists in the retrieved history to reconcile. Daniel has READ permission; this COMMENT is the technical conclusion, while effective approval and merge gates remain with a write-capable maintainer.

Snapshot 2026-11-01T11:47:24.438719+00:00: head 5c29f67137db482a52f8ddbef237e7630aeb4098, base dev; compare diverged, ahead 1 / behind 4; merge blocked / BLOCKED, review decision REVIEW_REQUIRED. Drift is recorded separately; it does not itself request synchronization.

[SEPURI-SAI-KRISHNA]

@DanielLeens thanks for the review. Issue 1 is done in the latest commit. JdbcMysqlIT and JdbcOceanBaseMysqlIT each get testCatalogReadsColumnTypesUnderTurkishLocale: it creates a table with int, int unsigned, bigint and datetime columns, sets tr-TR and then az-AZ in the test JVM, where the catalog runs, and reads the table through the catalog the IT already opens. The locale is restored in finally.

I checked that both detect the bug, against MySQL 8.0.43 and OceanBase CE 4.4.2.1. With this PR both pass. With the four changed classes as they are on dev, both fail with COMMON-20 ... {"c_int":"İNT","c_int_unsigned":"İNT","c_bigint":"BİGİNT","c_datetime":"DATETİME"}, and the locale is still restored. The existing testSetAndEnumColumnWithUnsignedWordInValueList and testEnumColumnWithUnsignedWordInValueList still pass. The PR description is updated.

[DanielLeens]

Thanks for the follow-up. I re-reviewed the current head 4f34fad2f1943c29f60f03da2f1d074d694e6b9c. The only change since my previous review (head 5c29f67137) is two new integration tests, JdbcMysqlIT.testCatalogReadsColumnTypesUnderTurkishLocale and JdbcOceanBaseMysqlIT.testCatalogReadsColumnTypesUnderTurkishLocale, which close the integration-coverage request I raised as Issue 1. The production changes are unchanged and I still find no functional defect in them.

What Problem Does This PR Solve?

User pain point: MySQL and OceanBase report DATA_TYPE in lower case. Under tr-TR / az-AZ the default-locale toUpperCase() turns int into a token with a dotted capital I, so catalog discovery fails with COMMON-17 unsupported convert type and a JDBC source using table_path cannot read almost any MySQL table.

Fix approach: use Locale.ROOT in MySqlCatalog, OceanBaseMySqlCatalog, MySqlTypeConverter and OceanBaseMySqlTypeConverter, and drop a redundant second upper-casing in the OceanBase catalog.

One-sentence summary: the same MySQL int unsigned column maps to LONG under a Turkish JVM exactly as it does under English.

1. Code Change Review

1.1 Core Logic Analysis

Before / after:

resultSet.getString("DATA_TYPE").toUpperCase()   ->  .toUpperCase(Locale.ROOT)      // MySqlCatalog:225, OceanBaseMySqlCatalog:146
typeDefine.getDataType().toUpperCase()           ->  .toUpperCase(Locale.ROOT)      // MySqlTypeConverter:199, OceanBaseMySqlTypeConverter:126
dataType.toUpperCase().startsWith("VECTOR")      ->  dataType.startsWith("VECTOR")  // value already upper case

Runtime path (read from the callers in this checkout):

JDBC source/sink with table_path
  -> MySqlCatalog / TiDBCatalog / OceanBaseMySqlCatalog.getTable
  -> buildColumn(ResultSet): DATA_TYPE normalized with ROOT -> unsigned detection (uses original COLUMN_TYPE)
  -> BasicTypeDefine -> MySqlTypeConverter / OceanBaseMySqlTypeConverter.convert (ROOT again) -> existing switch
  -> CatalogTable -> source schema / sink DDL

Key findings:

• The normal catalog-discovery path reaches the fix, not only a recovery path. TiDBCatalog inherits MySqlCatalog.buildColumn, so TiDB is fixed as well.
• I grepped the MySQL, TiDB and OceanBase catalog packages and the MySQL/OceanBase dialect packages. The remaining default-locale conversions are MysqlDialect:208 / OceanBaseMysqlDialect:207 (toLowerCase().contains("where"), no i, locale-neutral) and OceanBaseOracleCreateTableSqlBuilder:49 (Oracle mode, outside this PR).
• Removing the second toUpperCase() in OceanBaseMySqlCatalog is safe because the value is already upper case.
• The PR description correctly scopes out MySQL CDC (types arrive from Debezium's own parser) and the query path (Connector/J already reports upper case).
• Solution type: Precise fix.

1.2 Compatibility Impact

Fully compatible. No option, default, API/SPI, protocol, serialization or checkpoint change. Only inputs that failed under Turkish/Azerbaijani locales change; results under other locales are identical. No incompatible-changes.md entry is needed.

1.3 Performance / Side-Effect Analysis

Metadata-time only, one normalization per column as before (one fewer in the OceanBase catalog). No per-record work, thread, lock, connection or buffer is added.

1.4 Error Handling and Logging

Unsupported-type errors are unchanged. No new logging or credential exposure. No new issues found in this round.

2. Code Quality Assessment

2.1 Coding Standards

Minimal and consistent with existing style. No new production method or field, so no new Javadoc is required. New tests carry explanatory Javadoc.

2.2 Test Coverage and Test Stability

Stability rating: Stable.

• Unit tests (MySqlTypeConverterTest, OceanBaseMySqlTypeConverterTest, MySqlCatalogUnsignedDetectionTest, OceanBaseMySqlCatalogTest) use fixed inputs and restore the base locale and both category defaults in finally.
• New ITs, JdbcMysqlIT.java:633-692 and JdbcOceanBaseMysqlIT.java:343-402: create a table with int, int unsigned, bigint, datetime, switch the JVM default to tr-TR then az-AZ, read the table through the catalog the IT already opens, and assert exact types (INT, LONG, LONG, LOCAL_DATE_TIME). Locale is restored and the table dropped in finally. They are plain @Test methods with no sleeps or timing. I checked that neither IT closes the shared catalog in an earlier test. Reverting the Locale.ROOT changes would make the type assertions fail with the dotted-I names, so the tests have failure power. The contributor reports running both against MySQL 8.0.43 and OceanBase CE 4.4.2.1 with and without the fix; I did not run them.

2.3 Documentation Updates

No user-visible option or contract change; no EN/ZH doc update is needed.

3. Architectural Soundness

3.1 Elegance of the Solution

Precise fix at the metadata-token boundary in each affected class.

3.2 Maintainability

Small, mechanical, easy to audit.

3.3 Extensibility

Locale.ROOT is the right default for machine-defined tokens; other dialects with the same pattern can follow separately.

3.4 Historical-Version Compatibility

Existing jobs keep configuration and state formats; no checkpoint or serialization effect.

4. Issue Summary

Number	Issue	Location	Severity
-	No open issues. Previous Issue 1 (IT coverage) is resolved by the two new ITs.	-	-

5. Merge Recommendation

Conclusion: Ready to merge

1. Blockers
   • None on the source side.
2. Recommended non-blocking fixes
   • None.

CI state (checked at head 4f34fad2f1): the apache Build check is in_progress and the matching fork run is queued (run 41410003336). Please let it complete; the new ITs only get real CI evidence once the JDBC part-1 and part-2 lanes run. The branch is diverged by 4 commits behind dev with no conflict reported; I am not asking for a sync. Effective maintainer approval is a separate repository gate.

Overall assessment: the fix is correct and complete for the MySQL, TiDB and OceanBase (MySQL mode) catalog path, and the requested integration coverage is now present. I did not run any build or test locally; the conclusions come from reading the diff and callers.

[DanielLeens]

CI status update for head 4f34fad2f1: when I last reviewed this head, the current-head Build was still running, so I could not call CI yet. That run has now finished with a failure, so the CI fact in my previous comment is out of date. My source-side conclusion is unchanged.

What failed in the fork run (https://github.com/SEPURI-SAI-KRISHNA/seatunnel/actions/runs/41410003336): Run / edge-agent-it (11, ubuntu-latest). Specifically, the job failed while building/testing seatunnel-engine-server: JobHistoryServiceTest errored in AbstractSeaTunnelServerTest.before:73 with IllegalStateException (the Hazelcast test node did not start, after the 300 s limit).

That is an engine-server test bootstrap failure; it does not touch the MySQL/OceanBase catalog code this PR changes, so I do not attribute it to this diff. The branch already contains the related upstream Hazelcast join-port fix (#11868), so syncing with dev again would not change anything here.

The lowest-cost next step is to re-run only the failed jobs in your fork run ("Re-run failed jobs" on the run page). If the same test fails again on the re-run, please paste the new run link here and I will help narrow it down; please do not add unrelated changes to this PR just to chase it. Thanks again for your patience!

[SEPURI-SAI-KRISHNA]

Thanks @DanielLeens. The run you looked at was already the re-run of the failed jobs: https://github.com/SEPURI-SAI-KRISHNA/seatunnel/actions/runs/41410003336

• Attempt 1: unit-test (17, ubuntu-latest) failed on Redis7Test and edge-agent-it (11, ubuntu-latest) on JobHistoryServiceTest ("Node failed to start!" after 300 s).
• Attempt 2: unit-test (17, ubuntu-latest) passed; edge-agent-it (11, ubuntu-latest) failed again, same test, same error: https://github.com/SEPURI-SAI-KRISHNA/seatunnel/actions/runs/41410003336/job/125414045731

The same job passed on #13077 (run 41487880643), whose branch has the same dev base (f3e1c2e), and this PR changes no engine code. I have started one more re-run of the failed job and will post the result here.

[SEPURI-SAI-KRISHNA]

@DanielLeens as promised, the result of the extra re-run: attempt 3 of https://github.com/SEPURI-SAI-KRISHNA/seatunnel/actions/runs/41410003336 is green on the unchanged head 4f34fad2f1.

edge-agent-it (11, ubuntu-latest) passed (https://github.com/SEPURI-SAI-KRISHNA/seatunnel/actions/runs/41410003336/job/125716036689), and JobHistoryServiceTest ran 2 tests with 0 failures, with no "Node failed to start!" in the log. The Build check on this PR is now green.

[DanielLeens]

Thank you, @SEPURI-SAI-KRISHNA, for following through on the rerun and for posting the result. On the unchanged head 4f34fad2f1, attempt 3 of the fork run is green, edge-agent-it (11, ubuntu-latest) passed with JobHistoryServiceTest at 2 tests / 0 failures, and the apache Build check is now green. That confirms the earlier failure was the engine-server Hazelcast node-startup flake and not this change.

My source-side conclusion is unchanged: the Locale.ROOT fix in MySqlCatalog, OceanBaseMySqlCatalog, MySqlTypeConverter and OceanBaseMySqlTypeConverter is correct, and the two new ITs (JdbcMysqlIT and JdbcOceanBaseMysqlIT#testCatalogReadsColumnTypesUnderTurkishLocale) have real failure power. CI was the only remaining gate, so I am approving this head. Effective maintainer approval is still a separate repository gate. Thanks again!