apache/shardingsphere · error · SQLFeatureNotSupportedException

getSQLXML

Error message

getSQLXML

What it means

getSQLXML(int columnIndex) is declared final in AbstractUnsupportedDatabaseMetaDataResultSet and always throws SQLFeatureNotSupportedException. The ShardingSphere driver builds metadata result sets (for DatabaseMetaData.getTables(), getColumns(), etc.) from its own metadata model, which has no XML-typed column representation, so SQLXML extraction is intentionally unimplemented.

Source

Thrown at jdbc/src/main/java/org/apache/shardingsphere/driver/jdbc/unsupported/AbstractUnsupportedDatabaseMetaDataResultSet.java:151

    
    @Override
    public final Time getTime(final String columnLabel, final Calendar cal) throws SQLException {
        throw new SQLFeatureNotSupportedException("getTime(String columnLabel, Calendar cal)");
    }
    
    @Override
    public final Timestamp getTimestamp(final int columnIndex, final Calendar cal) throws SQLException {
        throw new SQLFeatureNotSupportedException("getTime(int columnIndex, Calendar cal)");
    }
    
    @Override
    public final Timestamp getTimestamp(final String columnLabel, final Calendar cal) throws SQLException {
        throw new SQLFeatureNotSupportedException("getTime(String columnLabel, Calendar cal)");
    }
    
    @Override
    public final SQLXML getSQLXML(final int columnIndex) throws SQLException {
        throw new SQLFeatureNotSupportedException("getSQLXML");
    }
    
    @Override
    public final SQLXML getSQLXML(final String columnLabel) throws SQLException {
        throw new SQLFeatureNotSupportedException("getSQLXML");
    }
}

View on GitHub (pinned to e952770a21)

Solutions

  1. Use rs.getString(columnIndex) or rs.getObject(columnIndex) instead; if XML processing is needed, parse the returned string with javax.xml parsers.
  2. Confirm the metadata result set never actually contains SQLXML columns (ShardingSphere metadata exposes names/types/remarks as strings), and remove the getSQLXML branch for this driver.
  3. If genuine SQLXML data access is required, do it on a normal query ResultSet against the underlying datasource, not on the metadata result set.
  4. Guard the call with a try-catch for SQLFeatureNotSupportedException as a defensive fallback.

Example fix

// before
SQLXML xml = rs.getSQLXML(3);

// after
String xml = rs.getString(3);
// parse xml with DocumentBuilder/StringReader if needed
Defensive patterns

Strategy: try-catch

Validate before calling

// Metadata columns in ShardingSphere are string-typed; probe cheaply:
int type = rs.getMetaData().getColumnType(col);
if (type == java.sql.Types.SQLXML) { /* vendor path */ } else { String v = rs.getString(col); }

Type guard

static boolean isShardingSphereResultSet(ResultSet rs) {
    return rs.getClass().getName().startsWith("org.apache.shardingsphere.driver.jdbc.");
}

Try / catch

try {
    sqlxml = rs.getSQLXML(col);
} catch (SQLFeatureNotSupportedException e) {
    xmlAsString = rs.getString(col); // parse if non-null
}

Prevention

When it happens

Trigger: Calling rs.getSQLXML(columnIndex) on the ResultSet returned by any org.apache.shardingsphere.driver DatabaseMetaData method (getTables, getColumns, getIndexInfo, ...).

Common situations: Generic metadata viewers or ORM introspection code that switches on ResultSetMetaData column type and calls getSQLXML for Types.SQLXML. Code migrated from a vendor driver (MySQL Connector/J, PgJDBC) that tolerates getSQLXML on metadata result sets to a jdbc:shardingsphere: URL.

Related errors


AI-assisted analysis of apache/shardingsphere@e952770a21 (2026-08-14). Data as JSON: /api/errors/ba67b8dfd6c48c5f. Report an issue: GitHub.