apache/shardingsphere · error · SQLFeatureNotSupportedException

getRef

Error message

getRef

What it means

getRef(int columnIndex) is final in AbstractUnsupportedOperationResultSet and unconditionally throws SQLFeatureNotSupportedException. SQL REF types are structured-type references that the sharding driver cannot resolve across shards, so the accessor is disabled even when the underlying database supports REF columns.

Source

Thrown at jdbc/src/main/java/org/apache/shardingsphere/driver/jdbc/unsupported/AbstractUnsupportedOperationResultSet.java:175

    
    @Override
    public final NClob getNClob(final String columnLabel) throws SQLException {
        throw new SQLFeatureNotSupportedException("getNClob");
    }
    
    @Override
    public final Reader getNCharacterStream(final int columnIndex) throws SQLException {
        throw new SQLFeatureNotSupportedException("getNCharacterStream");
    }
    
    @Override
    public final Reader getNCharacterStream(final String columnLabel) throws SQLException {
        throw new SQLFeatureNotSupportedException("getNCharacterStream");
    }
    
    @Override
    public final Ref getRef(final int columnIndex) throws SQLException {
        throw new SQLFeatureNotSupportedException("getRef");
    }
    
    @Override
    public final Ref getRef(final String columnLabel) throws SQLException {
        throw new SQLFeatureNotSupportedException("getRef");
    }
    
    @Override
    public final RowId getRowId(final int columnIndex) throws SQLException {
        throw new SQLFeatureNotSupportedException("getRowId");
    }
    
    @Override
    public final RowId getRowId(final String columnLabel) throws SQLException {
        throw new SQLFeatureNotSupportedException("getRowId");
    }
    
    @Override

View on GitHub (pinned to e952770a21)

Solutions

  1. Fetch the reference as its underlying representation: getObject(columnIndex) or getString(columnIndex), and dereference manually with a keyed SELECT on the target table.
  2. Model the relationship with ordinary foreign-key columns plus JOIN queries instead of SQL REFs when sharding.
  3. Remove/guard the getRef branch in type-dispatch code when running under ShardingSphere.

Example fix

// before
Ref ref = rs.getRef(4); // throws
Object target = ref.getObject();

// after
Object refKey = rs.getObject(4);
// then: SELECT ... FROM target_table WHERE id = ?
Defensive patterns

Strategy: try-catch

Validate before calling

int type = rs.getMetaData().getColumnType(col);
if (type == Types.REF) { Object key = rs.getObject(col); /* deref manually */ }

Type guard

boolean isRefColumn(ResultSetMetaData md, int col) throws SQLException {
    return md.getColumnType(col) == Types.REF;
}

Try / catch

try {
    ref = rs.getRef(col);
} catch (SQLFeatureNotSupportedException e) {
    Object key = rs.getObject(col);
    target = fetchByKey(conn, key);
}

Prevention

When it happens

Trigger: Calling ResultSet.getRef(columnIndex) on a ResultSet from ShardingSphereDataSource — usually generic type-dispatch mappers that handle java.sql.Types.REF, or code ported from object-relational schemas (Oracle REF, SQL:1999 structured types).

Common situations: Object-relational database features used behind the sharding layer; row mappers with exhaustive Types switches that call getRef for REF columns; migration from drivers where REF columns return java.sql.Ref.

Related errors


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