zhengxiang378928908-code opened a new pull request, #11684:
URL: https://github.com/apache/seatunnel/pull/11684
### Purpose of this pull request
Fixes #10635.
`DmdbTypeConverter` recognises `NVARCHAR` but not `NVARCHAR2`, which Dameng
also accepts as the Oracle-compatible synonym of `NVARCHAR`. Reading a Dameng
table that has `NVARCHAR2` columns therefore falls through to the `default`
branch and fails:
```
ErrorCode:[COMMON-17], ErrorDescription:['Dameng' unsupported convert type
'nvarchar2' of 'test' to SeaTunnel data type.]
```
In a multi-table job (`table_list`) the catalog aggregates these into the
`COMMON-21` error reported in the issue, and the whole job fails before any
data is read:
```
ErrorCode:[COMMON-21], ErrorDescription:['Dameng' tables unsupported get
catalog table，
the corresponding field types in the following tables are not supported:
'{"test.test_nvarchar2":{"id":"nvarchar2","name":"nvarchar2","age":"nvarchar2"}}'
```
This PR maps `NVARCHAR2` to `STRING` alongside the existing `NVARCHAR` case.
The `sourceType` is now built from the matched type name rather than the
hard-coded `NVARCHAR` constant, so an `NVARCHAR2` column reports `NVARCHAR2(n)`
and an `NVARCHAR` column keeps reporting `NVARCHAR(n)` exactly as before.
Column length handling (`charTo4ByteLength`) is shared with the existing
`NVARCHAR` path and is unchanged.
The scope is deliberately limited to the type conversion failure described
in the issue.
### Does this PR introduce _any_ user-facing change?
Yes, in the sense that a previously failing configuration now works: Dameng
tables containing `NVARCHAR2` columns can now be read by the JDBC source, and
those columns are mapped to SeaTunnel `STRING`.
There is no change to any config option, default value, or existing type
mapping. `NVARCHAR` behaviour is byte-for-byte identical to before, so this is
backward compatible.
### How was this patch tested?
Extended the existing `DmdbTypeConverterTest#testNvarchar` unit test with an
`nvarchar2(2)` case asserting the mapped data type, column length and source
type.
```
./mvnw test -pl seatunnel-connectors-v2/connector-jdbc
-Dtest=DmdbTypeConverterTest
Tests run: 34, Failures: 0, Errors: 0, Skipped: 0
```
I also confirmed the new assertion actually reproduces the reported bug —
reverting only the `DmdbTypeConverter` change makes it fail with the exact
error from the issue:
```
[ERROR] testNvarchar Time elapsed: 0.117 s <<< ERROR!
org.apache.seatunnel.common.exception.SeaTunnelRuntimeException:
ErrorCode:[COMMON-17],
ErrorDescription:['Dameng' unsupported convert type 'nvarchar2' of 'test' to
SeaTunnel data type.]
```
`./mvnw spotless:apply` was run over the module.
No E2E test was added: there is no Dameng E2E suite in `seatunnel-e2e`
(Dameng has no publicly available test image), and the defect is entirely in
pure type-mapping logic that the unit test covers directly.
### Related follow-up (not in this PR)
While investigating I noticed `DamengCatalog#SELECT_COLUMNS_SQL` omits
`NVARCHAR`/`NVARCHAR2` from the `CASE` branch that appends the length to
`SOURCE_TYPE`, so those columns report a bare type name without `(n)`. That is
cosmetic, does not affect this failure, and I could not verify whether
`ALL_TAB_COLUMNS.DATA_LENGTH` is expressed in bytes or characters for national
character types without a real Dameng instance. I left it out to keep this PR
focused, and I'm happy to open a separate issue for it.
### 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]
