zhengxiang378928908-code opened a new pull request, #11686:
URL: https://github.com/apache/seatunnel/pull/11686
### Purpose of this pull request
Fixes #11685.
`YashanDbTypeConverter` has cases for `CHAR`/`VARCHAR` and
`NCHAR`/`NVARCHAR`, but not for the Oracle-compatible synonyms `VARCHAR2` and
`NVARCHAR2`. Reading a YashanDB table containing such columns falls through to
the `default` branch and fails:
```
ErrorCode:[COMMON-17], ErrorDescription:['YashanDB' unsupported convert type
'VARCHAR2' of 'test' to SeaTunnel data type.]
```
The connector's own catalog layer already contradicts this.
`YashanDbCatalog#SELECT_COLUMNS_SQL` expects both types, and groups them by
length semantics:
```sql
WHEN cols.data_type IN ('VARCHAR', 'VARCHAR2', 'CHAR') THEN '(' ||
cols.data_length || ')'
WHEN cols.data_type IN ('NVARCHAR2', 'NCHAR') THEN '(' ||
cols.char_length || ')'
```
That grouping determines where each synonym belongs in the converter, and
this PR follows it exactly:
| Type | Catalog length column | Semantics | Converter branch |
| --- | --- | --- | --- |
| `VARCHAR2` | `data_length` | byte | joins `CHAR`/`VARCHAR` →
`charTo4ByteLength` |
| `NVARCHAR2` | `char_length` | character | joins `NCHAR`/`NVARCHAR` →
`doubleByteTo4ByteLength` |
So the mapping is not inferred from external YashanDB documentation — it is
taken from the length semantics this connector already encodes for the same
types.
`convert()` sets `sourceType` centrally from `typeDefine.getColumnType()`,
so the declared type name is preserved automatically and no per-branch handling
is needed.
`reconvert()` (sink direction) is unchanged: it continues to emit `VARCHAR`
for `STRING` columns.
### Does this PR introduce _any_ user-facing change?
Yes, in the sense that a previously failing configuration now works:
YashanDB tables containing `VARCHAR2` or `NVARCHAR2` columns can now be read,
and those columns map to SeaTunnel `STRING`.
No config option, default value, or existing type mapping changes. The added
cases are purely additive — `CHAR`, `VARCHAR`, `NCHAR` and `NVARCHAR` behave
exactly as before — so this is backward compatible.
### How was this patch tested?
Extended the existing `YashanDbTypeConverterTest#testConvertCharTypes` with
`VARCHAR2(100)` and `NVARCHAR2(100)` cases, asserting the mapped data type, the
column length produced by each length rule (400 and 200 respectively), and that
`sourceType` is preserved.
```
./mvnw test -pl seatunnel-connectors-v2/connector-jdbc
-Dtest=YashanDbTypeConverterTest
Tests run: 32, Failures: 0, Errors: 0, Skipped: 0
```
I also confirmed the new assertions actually reproduce the bug — reverting
only the `YashanDbTypeConverter` change makes the test fail with the reported
error:
```
[ERROR] testConvertCharTypes Time elapsed: 0.089 s <<< ERROR!
org.apache.seatunnel.common.exception.SeaTunnelRuntimeException:
ErrorCode:[COMMON-17],
ErrorDescription:['YashanDB' unsupported convert type 'VARCHAR2' of 'test'
to SeaTunnel data type.]
```
`./mvnw spotless:apply` was run over the module.
No E2E test was added: there is no YashanDB E2E suite in `seatunnel-e2e` and
no publicly available test image, and the defect is entirely in pure
type-mapping logic that the unit test covers directly.
### Check list
* [x] If any new Jar binary package adding in your PR, please add License
Notice according
[New License
Guide](https://github.com/apache/seatunnel/blob/dev/docs/en/developer/new-license.md)
— no new dependency
* [x] If necessary, please update the documentation to describe the new
feature. https://github.com/apache/seatunnel/tree/dev/docs — not applicable, no
option or documented behaviour changed
* [x] If necessary, please update `incompatible-changes.md` to describe the
incompatibility caused by this PR — not applicable, change is backward
compatible
* [x] If you are contributing the connector code, please check that the
following files are updated — not applicable, no new connector
--
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]
