【SQL Federation】SQL Federation ResultSetMetaData#getColumnClassName returns SqlTypeName enum class instead of actual Java column class

[YM-Sky]

Bug Report

Which version of ShardingSphere did you use?

Apache ShardingSphere-JDBC 5.5.3.

Related modules:

• shardingsphere-jdbc: 5.5.3
• shardingsphere-jdbc-dialect-mysql: 5.5.3
• shardingsphere-sharding-mysql: 5.5.3

Environment:

• Java 17
• MySQL dialect
• SQL Federation enabled
• Apache Calcite resolved as 1.40.0

Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy?

ShardingSphere-JDBC.

Expected behavior

For SQL Federation query results, ResultSetMetaData#getColumnClassName(column) should return the Java class name corresponding to the actual result column type.

For example:

• BIGINT id column: java.lang.Long
• VARCHAR name column: java.lang.String
• DECIMAL column: java.math.BigDecimal

Actual behavior

ResultSetMetaData#getColumnClassName(column) returns:

org.apache.calcite.sql.type.SqlTypeName

This happens for normal result columns such as id BIGINT.

When a mapper framework maps results to Map<String, Object>, it may use the reported column class name to select a type handler. Since ShardingSphere reports the enum class SqlTypeName, MyBatis/MyBatis-Plus chooses an enum type handler and tries to parse the actual database value as a SqlTypeName enum constant.

Stack trace excerpt:

Caused by: org.apache.ibatis.executor.result.ResultMapException:
Error attempting to get column 'id' from result set.
Cause: java.lang.IllegalArgumentException:
No enum constant org.apache.calcite.sql.type.SqlTypeName.2076978610812633090

at org.apache.ibatis.type.BaseTypeHandler.getResult(BaseTypeHandler.java:88)
at com.baomidou.mybatisplus.core.handlers.CompositeEnumTypeHandler.getResult(CompositeEnumTypeHandler.java:62)
at org.apache.ibatis.executor.resultset.DefaultResultSetHandler.applyAutomaticMappings(DefaultResultSetHandler.java:582)

Caused by: java.lang.IllegalArgumentException:
No enum constant org.apache.calcite.sql.type.SqlTypeName.2076978610812633090
at java.lang.Enum.valueOf(Enum.java:273)
at org.apache.ibatis.type.EnumTypeHandler.getNullableResult(EnumTypeHandler.java:49)

Reason analyze (If you can)

I checked the ShardingSphere 5.5.3 source locally.

Source location:

D:\source\shardingsphere\shardingsphere-5.5.3\kernel\sql-federation\core\src\main\java\org\apache\shardingsphere\sqlfederation\resultset\SQLFederationResultSetMetaData.java

Current implementation:

@Override
public String getColumnClassName(final int column) {
    return resultColumnType.getFieldList().get(column - 1).getType().getSqlTypeName().getClass().getName();
}

getSqlTypeName() returns a Calcite enum value. Calling getClass().getName() on that enum value always returns:

org.apache.calcite.sql.type.SqlTypeName

It does not return the actual Java class for the result column.

Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.

Use ShardingSphere-JDBC 5.5.3 with MySQL dialect and SQL Federation enabled.

Sanitized YAML, preserving the real rule structure:

databaseName: logic_db

mode:
  type: Standalone
  repository:
    type: JDBC

transaction:
  defaultType: LOCAL

dataSources:
  ds_0:
    dataSourceClassName: com.zaxxer.hikari.HikariDataSource
    driverClassName: com.mysql.cj.jdbc.Driver
    jdbcUrl: jdbc:mysql://127.0.0.1:3306/demo_master?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai
    username: root
    password: password
  ds_1:
    dataSourceClassName: com.zaxxer.hikari.HikariDataSource
    driverClassName: com.mysql.cj.jdbc.Driver
    jdbcUrl: jdbc:mysql://127.0.0.1:3306/demo_sharding_1?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai
    username: root
    password: password

sqlFederation:
  sqlFederationEnabled: true
  allQueryUseSQLFederation: false
  executionPlanCache:
    initialCapacity: 2000
    maximumSize: 65535

props:
  sql-show: true

rules:
  - !SINGLE
    tables:
      - ds_0.mnt_base_user

  - !SHARDING
    tables: {}
    defaultDatabaseStrategy:
      complex:
        shardingColumns: tenant_id
        shardingAlgorithmName: custom_database_tenant_sharding_algorithm
    defaultTableStrategy:
      complex:
        shardingColumns: tenant_id
        shardingAlgorithmName: tenant_sharding_algorithm
    shardingAlgorithms:
      custom_database_tenant_sharding_algorithm:
        type: CLASS_BASED
        props:
          strategy: COMPLEX
          algorithmClassName: com.example.sharding.CustomDatabaseTenantIdShardingAlgorithm
          dbPrefix: ds_
          tenantIdFiled: tenant_id
      tenant_sharding_algorithm:
        type: CLASS_BASED
        props:
          strategy: COMPLEX
          algorithmClassName: com.example.sharding.CustomTableTenantIdShardingAlgorithm
          tenantIdFiled: tenant_id

Run a SQL Federation query:

SELECT so.id AS id, u.name AS record_user_name
FROM ims_sales_order so
LEFT JOIN mnt_base_user u ON so.record_user_id = u.id
WHERE so.tenant_id = 1
ORDER BY so.create_time DESC
LIMIT 20

Then inspect metadata:

try (ResultSet rs = ps.executeQuery()) {
    ResultSetMetaData md = rs.getMetaData();
    System.out.println(md.getColumnClassName(1));
}

Expected:

java.lang.Long

Actual:

org.apache.calcite.sql.type.SqlTypeName

Example codes for reproduce this issue (such as a github link).

try (Connection connection = dataSource.getConnection();
     PreparedStatement ps = connection.prepareStatement("""
         SELECT so.id AS id, u.name AS record_user_name
         FROM ims_sales_order so
         LEFT JOIN mnt_base_user u ON so.record_user_id = u.id
         WHERE so.tenant_id = 1
         ORDER BY so.create_time DESC
         LIMIT 20
         """);
     ResultSet rs = ps.executeQuery()) {

    ResultSetMetaData md = rs.getMetaData();

    // Actual in SQL Federation: org.apache.calcite.sql.type.SqlTypeName
    // Expected for BIGINT id: java.lang.Long
    System.out.println(md.getColumnClassName(1));
}

Suggested fix

SQLFederationResultSetMetaData#getColumnClassName should map Calcite SqlTypeName or RelDataType to the correct JDBC Java class name.

Possible mapping examples:

• BIGINT -> java.lang.Long
• INTEGER -> java.lang.Integer
• VARCHAR/CHAR -> java.lang.String
• DECIMAL -> java.math.BigDecimal
• BOOLEAN -> java.lang.Boolean
• DATE/TIME/TIMESTAMP -> corresponding JDBC date/time classes
• Unknown fallback -> java.lang.Object

The method should not return getSqlTypeName().getClass().getName(), because that returns the enum implementation class, not the result column Java class.

[terrymanu]

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) OBS-1
• Topology: ShardingSphere-JDBC + Standalone mode, using a JDBC standalone repository. OBS-1
• Supported Scenario: The official SQL Federation documentation 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)
• 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)
• 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)
• Observation (OBS-6): Repository history traces the incorrect expression to #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 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)