terrymanu commented on issue #39121: URL: https://github.com/apache/shardingsphere/issues/39121#issuecomment-5004476356
Hi @YM-Sky, thanks for the detailed report. This is a valid bug in SQL Federation result metadata, not unsupported usage or a duplicate. In both ShardingSphere 5.5.3 and current master, `SQLFederationResultSetMetaData#getColumnClassName` calls `getClass()` on a Calcite `SqlTypeName` enum value, so it returns `org.apache.calcite.sql.type.SqlTypeName` regardless of the actual result-column type. The current unit test also incorrectly preserves that behavior. The fix should derive the Java class from the effective result/JDBC type and keep it consistent with dialect-specific type/value conversion. Please replace the current assertion with coverage for representative numeric, character, temporal, binary, and fallback types, plus a ShardingSphere-JDBC SQL Federation metadata test. Contributors are welcome to submit a PR with code and tests. I suggest labeling this as `type: bug`, `feature: SQL federation`, and `in: JDBC`. The reply above is based on the analysis below; the detailed reasoning is kept here for reference and follow-up contributors. ### Problem Understanding - **Issue:** With ShardingSphere-JDBC 5.5.3, MySQL dialect, and SQL Federation enabled, `ResultSetMetaData#getColumnClassName` reports `org.apache.calcite.sql.type.SqlTypeName`; MyBatis consequently selects an enum handler and fails while reading a `BIGINT` value. The issue includes SQL, YAML, expected/actual output, and a stack trace. ([#39121](https://github.com/apache/shardingsphere/issues/39121)) `OBS-1` - **Topology:** ShardingSphere-JDBC + Standalone mode, using a JDBC standalone repository. `OBS-1` - **Supported Scenario:** The official [SQL Federation documentation](https://shardingsphere.apache.org/document/current/en/features/sql-federation/) identifies cross-database joins as an intended application scenario. The configuration documentation marks the feature experimental, but the reported usage is valid. `OBS-2` - **Observed Evidence:** `OBS-1`, `OBS-2`, `OBS-3`, `OBS-4`, `OBS-5`, `OBS-6` ### Root Cause - **Observation (`OBS-3`):** `kernel/sql-federation/core/src/main/java/org/apache/shardingsphere/sqlfederation/resultset/SQLFederationResultSetMetaData.java:182` returns `relDataType.getSqlTypeName().getClass().getName()`. Since `getSqlTypeName()` returns an enum value, `getClass()` describes the enum implementation rather than the result value. ([current master source](https://github.com/apache/shardingsphere/blob/5c0e8aac13e35850b71bac61832de1e8881844cb/kernel/sql-federation/core/src/main/java/org/apache/shardingsphere/sqlfederation/resultset/SQLFederationResultSetMetaData.java#L182-L184)) - **Observation (`OBS-4`):** `kernel/sql-federation/core/src/test/java/org/apache/shardingsphere/sqlfederation/resultset/SQLFederationResultSetMetaDataTest.java:353` explicitly expects `SqlTypeName.VARCHAR.getClass().getName()`, so the test protects the incorrect implementation. ([current test](https://github.com/apache/shardingsphere/blob/5c0e8aac13e35850b71bac61832de1e8881844cb/kernel/sql-federation/core/src/test/java/org/apache/shardingsphere/sqlfederation/resultset/SQLFederationResultSetMetaDataTest.java#L352-L360)) - **Observation (`OBS-5`):** Current ShardingSphere metadata code maps effective JDBC types to Java classes such as `Long`, `String`, and `BigDecimal` in `infra/executor/src/main/java/org/apache/shardingsphere/infra/executor/sql/execute/result/query/impl/raw/metadata/RawResultSetMetaData.java:149`. This is a useful project-level behavioral reference, although the SQL Federation implementation must also respect its dialect converter. ([source](https://github.com/apache/shardingsphere/blob/5c0e8aac13e35850b71bac61832de1e8881844cb/infra/executor/src/main/java/org/apache/shardingsphere/infra/executor/sql/execute/result/query/impl/raw/metadata/RawResultSetMetaData.java#L148-L193)) - **Observation (`OBS-6`):** Repository history traces the incorrect expression to [#21063](https://github.com/apache/shardingsphere/pull/21063), where it was added during an unrelated column-label fix. The same expression remains in 5.5.3 and current master. - **Inference (`INF-1`, from `OBS-1`, `OBS-3`, `OBS-4`):** The failure is deterministic and independent of the MySQL server version: every `SqlTypeName` value produces the same enum class name. - **Inference (`INF-2`, from `OBS-2`, `OBS-3`):** This is an implementation bug, not invalid configuration or an unsupported SQL Federation scenario. - **Confidence:** High ### Problem Analysis - **Fast Triage:** Reproduction evidence is sufficient; official documentation confirms the usage scenario, although it does not specify the detailed JDBC metadata mapping; repository code and tests directly confirm the faulty behavior. `OBS-1`–`OBS-5` - **Issue Type:** Bug (`INF-1`, `INF-2`) - **Duplicate Check:** Exact searches for the method, class, and exception found no earlier fixing issue or PR. [#27428](https://github.com/apache/shardingsphere/issues/27428) contains a superficially similar `SqlTypeName` exception, but it is a Proxy/openGauss `REGCLASS` conversion failure in `TypeCastExpressionConverter`, not this JDBC metadata path. `OBS-6` - **Compatibility Checklist:** Behavior changes intentionally; no configuration, API/SPI signature, or SQL execution-semantics change is required. `OBS-3`, `OBS-5` ### Code-Level Design Suggestions - **Affected Modules:** Limit the production change to `kernel/sql-federation/core` unless dialect-consistency evidence requires a narrowly scoped converter change. `OBS-3`, `OBS-5` - **Key Classes:** `SQLFederationResultSetMetaData` and `SQLFederationResultSetMetaDataTest`. Validate consistency with `DialectSQLFederationColumnTypeConverter` because `getColumnType` and returned values already use dialect conversion. - **Type Contract:** Resolve the class from the effective result/JDBC type, not from the runtime class of the `SqlTypeName` enum. Keep `getColumnClassName`, `getColumnType`, and `getObject` mutually consistent, including MySQL boolean/`ANY` conversion and the existing `BigInteger` handling. - **Required Test Scope:** Replace the enum-class expectation with parameterized behavioral cases for `BIGINT`, integer, `VARCHAR`, `DECIMAL`, boolean, temporal, binary, and unknown/fallback types. Add cases for dialect-converted and Java-backed `RelDataType` values. Add one ShardingSphere-JDBC SQL Federation sentinel that asserts both the metadata class name and the corresponding `getObject` value without introducing a MyBatis dependency. - **Rollback Hint:** Keep the change isolated to metadata resolution and its focused tests so it can be reverted independently if a driver-specific compatibility regression is found. ### Problem Conclusion - **Evidence Confidence:** High (`OBS-1`–`OBS-6`; `INF-1`) - **Severity:** S2 — SQL execution can succeed, but frameworks relying on result metadata may fail to consume the result (`OBS-1`; `INF-1`) - **Impact Scope:** One SQL Federation metadata class; confirmed for ShardingSphere-JDBC with MySQL and potentially applicable to every dialect using the same generic class (`OBS-1`, `OBS-3`; `INF-1`) - **Topology:** ShardingSphere-JDBC + Standalone, JDBC repository (`OBS-1`) - **Issue Type:** Bug (`OBS-1`, `OBS-3`, `OBS-4`; `INF-1`, `INF-2`) - **Recommended Labels:** `type: bug`, `feature: SQL federation`, `in: JDBC` (`OBS-1`, `OBS-3`) - **Next Action:** Accept the issue as a bug and invite a focused PR correcting class resolution with unit and JDBC SQL Federation regression tests (`OBS-3`–`OBS-5`; `INF-1`) - **Compatibility:** Behavior: corrected JDBC metadata; Config: none; API-SPI: none; SQL: none (`OBS-3`, `OBS-5`) - **Regression Scope:** SQL Federation metadata for common and dialect-converted types, Java-backed result types, computed expressions, and unknown-type fallback (`OBS-3`–`OBS-5`) -- 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]
