What causes "getRow" in apache/shardingsphere?

Maintain your own counter incremented with every successful rs.next().

apache/shardingsphere · error · SQLFeatureNotSupportedException

getRow

Error message

getRow

What it means

getRow() returns the current row number (1-based), but ShardingSphere's AbstractUnsupportedOperationResultSet makes it final and throwing because forward-only merge results do not maintain a row counter for position queries. Callers see SQLFeatureNotSupportedException instead of a number.

Source

Thrown at jdbc/src/main/java/org/apache/shardingsphere/driver/jdbc/unsupported/AbstractUnsupportedOperationResultSet.java:90

    
    @Override
    public final boolean last() throws SQLException {
        throw new SQLFeatureNotSupportedException("last");
    }
    
    @Override
    public final boolean absolute(final int row) throws SQLException {
        throw new SQLFeatureNotSupportedException("absolute");
    }
    
    @Override
    public final boolean relative(final int rows) throws SQLException {
        throw new SQLFeatureNotSupportedException("relative");
    }
    
    @Override
    public final int getRow() throws SQLException {
        throw new SQLFeatureNotSupportedException("getRow");
    }
    
    @Override
    public final void insertRow() throws SQLException {
        throw new SQLFeatureNotSupportedException("insertRow");
    }
    
    @Override
    public final void updateRow() throws SQLException {
        throw new SQLFeatureNotSupportedException("updateRow");
    }
    
    @Override
    public final void deleteRow() throws SQLException {
        throw new SQLFeatureNotSupportedException("deleteRow");
    }
    
    @Override

View on GitHub (pinned to e952770a21)

Solutions

Maintain your own counter incremented with every successful rs.next().
For total counts, execute SELECT COUNT(*) separately.
If ordinals are needed after iteration, store rows in an indexed List.
For displaying progress on huge merges, log per N iterations of your own counter.

Example fix

// before
while (rs.next()) { log.info("row {}", rs.getRow()); } // throws

// after
int row = 0;
while (rs.next()) { row++; log.info("row {}", row); }

Defensive patterns

Strategy: validation

Validate before calling

if (rs.getType() == ResultSet.TYPE_FORWARD_ONLY) {
    int row = 0;
    while (rs.next()) { row++; } // maintain your own row number
}

Try / catch

try {
    int n = rs.getRow();
} catch (SQLFeatureNotSupportedException e) {
    // use the local counter incremented alongside next()
}

Prevention

Pair every iteration with a local row counter instead of getRow().
Use COUNT(*) for totals; never the last()+getRow() idiom on sharded results.
Keep position logic in your code, not in ResultSet probes.

When it happens

Trigger: Calling rs.getRow() during iteration — typically for progress logging or as the rs.last()+getRow() row-count idiom — on any ShardingSphere-driver query.

Common situations: Progress counters in batch processors; row-count tricks ported from scrollable cursors; frameworks that tag rows with their ordinal via getRow().

Related errors

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