apache/shardingsphere · error · SQLFeatureNotSupportedException
setRowId
Error message
setRowId
What it means
SQLFeatureNotSupportedException('setRowId') thrown by AbstractUnsupportedOperationPreparedStatement.setRowId(int, RowId). java.sql.RowId is an opaque driver/vendor handle (Oracle ROWID, DB2 RID) that cannot survive ShardingSphere's parse-and-rebind pipeline across heterogeneous backends; the method is final and always throws.
Source
Thrown at jdbc/src/main/java/org/apache/shardingsphere/driver/jdbc/unsupported/AbstractUnsupportedOperationPreparedStatement.java:79
@Override
public final void setNClob(final int parameterIndex, final Reader x, final long length) throws SQLException {
throw new SQLFeatureNotSupportedException("setNClob");
}
@Override
public final void setNCharacterStream(final int parameterIndex, final Reader x) throws SQLException {
throw new SQLFeatureNotSupportedException("setNCharacterStream");
}
@Override
public final void setNCharacterStream(final int parameterIndex, final Reader x, final long length) throws SQLException {
throw new SQLFeatureNotSupportedException("setNCharacterStream");
}
@Override
public final void setRowId(final int parameterIndex, final RowId x) throws SQLException {
throw new SQLFeatureNotSupportedException("setRowId");
}
@Override
public final void setRef(final int parameterIndex, final Ref x) throws SQLException {
throw new SQLFeatureNotSupportedException("setRef");
}
@Override
public final ResultSet executeQuery(final String sql) throws SQLException {
throw new SQLFeatureNotSupportedException("executeQuery with SQL for PreparedStatement");
}
@Override
public final int executeUpdate(final String sql) throws SQLException {
throw new SQLFeatureNotSupportedException("executeUpdate with SQL for PreparedStatement");
}
@OverrideView on GitHub (pinned to e952770a21)
Solutions
- Bind the ROWID as its string form: ps.setString(1, rowId.toString()) when the backend accepts it (Oracle does).
- Replace ROWID-based access with the table's real primary key — required anyway for consistent sharding routing.
- Remove the generic RowId branch from your binder; no ShardingSphere backend path supports it.
Example fix
// before ps.setRowId(1, rowId); // after ps.setString(1, rowId.toString()); // or better: WHERE id = ? with the primary key
Defensive patterns
Strategy: fallback
Validate before calling
if (value instanceof RowId) { ps.setString(idx, ((RowId) value).toString()); } else { ps.setObject(idx, value); } Prevention
- Never bind java.sql.RowId through sharded connections
- Use primary keys instead of ROWID for row addressing
- Bind ROWID strings via setString where the backend accepts them
When it happens
Trigger: ps.setRowId(1, rowId) on a ShardingSphere PreparedStatement; realistically reached only by generic binders that dispatch on instanceof RowId, or code written against Oracle's ROWID pseudo-column.
Common situations: Oracle ROWID-optimization code (WHERE ROWID = ?) reused in a sharded environment; ORM custom types for vendor ROWID columns; speculative code copied from JDBC documentation.
Related errors
AI-assisted analysis of apache/shardingsphere@e952770a21 (2026-08-14).
Data as JSON: /api/errors/f7160c6f57f13abf.
Report an issue: GitHub.