apache/shardingsphere · error · SQLFeatureNotSupportedException

rowInserted

Error message

rowInserted

What it means

rowInserted() — reporting whether the current row was inserted via the ResultSet insert-row — throws SQLFeatureNotSupportedException in the federation ResultSet. Because inserts through the cursor are unsupported, visibility-of-inserts queries are also unsupported; the method is final and rejects every call.

Source

Thrown at kernel/sql-federation/core/src/main/java/org/apache/shardingsphere/sqlfederation/resultset/AbstractUnsupportedOperationSQLFederationResultSet.java:130

    
    @Override
    public final void cancelRowUpdates() throws SQLException {
        throw new SQLFeatureNotSupportedException("cancelRowUpdates");
    }
    
    @Override
    public final void moveToInsertRow() throws SQLException {
        throw new SQLFeatureNotSupportedException("moveToInsertRow");
    }
    
    @Override
    public final void moveToCurrentRow() throws SQLException {
        throw new SQLFeatureNotSupportedException("moveToCurrentRow");
    }
    
    @Override
    public final boolean rowInserted() throws SQLException {
        throw new SQLFeatureNotSupportedException("rowInserted");
    }
    
    @Override
    public final boolean rowUpdated() throws SQLException {
        throw new SQLFeatureNotSupportedException("rowUpdated");
    }
    
    @Override
    public final boolean rowDeleted() throws SQLException {
        throw new SQLFeatureNotSupportedException("rowDeleted");
    }
    
    @Override
    public final String getCursorName() throws SQLException {
        throw new SQLFeatureNotSupportedException("getCursorName");
    }
    
    @Override

View on GitHub (pinned to e952770a21)

Solutions

  1. Remove visibility checks: track which rows your own code inserted/updated/deleted in application state
  2. If detecting external concurrent changes, use a version/timestamp column or CHANGE detection query instead of rowInserted()
  3. Wrap third-party code you cannot change so federation connections are not passed to visibility-check loops

Example fix

// before
while (rs.next()) { if (rs.rowInserted()) continue; ... }

// after
Set<Long> insertedIds = ...; // tracked by your code
while (rs.next()) { if (insertedIds.contains(rs.getLong("id"))) continue; ... }
Defensive patterns

Strategy: try-catch

Validate before calling

try { rs.rowInserted(); /* supported */ }
catch (final SQLFeatureNotSupportedException e) { /* visibility unsupported: track own inserts in a Set */ }

Type guard

private boolean isFederationVisibilitySupported(final ResultSet rs) {
    return rs.getClass().getName().startsWith("org.apache.shardingsphere.sqlfederation") == false;
}

Try / catch

boolean inserted;
try { inserted = rs.rowInserted(); }
catch (final SQLFeatureNotSupportedException e) { inserted = ownInsertedIds.contains(id); }

Prevention

When it happens

Trigger: Calling rs.rowInserted() while iterating a federated ResultSet, e.g. change-detection loops that branch on rowInserted()/rowUpdated()/rowDeleted() visibility flags.

Common situations: Sync/ETL code that distinguishes own-cursor changes from external changes using the JDBC visibility methods; ported code that assumes default JDBC visibility behavior (inserts visible = false at minimum per spec) instead of handling the exception; running such loops against ShardingSphere federation for the first time.

Related errors


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