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");
}
@OverrideView on GitHub (pinned to e952770a21)
Solutions
- Fetch the reference as its underlying representation: getObject(columnIndex) or getString(columnIndex), and dereference manually with a keyed SELECT on the target table.
- Model the relationship with ordinary foreign-key columns plus JOIN queries instead of SQL REFs when sharding.
- 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
- Avoid SQL REF/structured types in schemas that sit behind sharding.
- Model references as FK columns plus JOINs.
- Dereference references manually with keyed SELECTs.
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.