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");
    }
    
    @Override

View on GitHub (pinned to e952770a21)

Solutions

  1. Bind the ROWID as its string form: ps.setString(1, rowId.toString()) when the backend accepts it (Oracle does).
  2. Replace ROWID-based access with the table's real primary key — required anyway for consistent sharding routing.
  3. 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

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.