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");
}
@OverrideView on GitHub (pinned to e952770a21)
Solutions
- Remove visibility checks: track which rows your own code inserted/updated/deleted in application state
- If detecting external concurrent changes, use a version/timestamp column or CHANGE detection query instead of rowInserted()
- 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
- Track own mutations in application state
- Never branch on visibility flags for federation reads
- Wrap change-detection loops in capability-aware helpers
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.