apache/shardingsphere · error · SQLFeatureNotSupportedException
getBlob
Error message
getBlob
What it means
getBlob(int columnIndex) unconditionally throws SQLFeatureNotSupportedException("getBlob") in AbstractUnsupportedGeneratedKeysResultSet:192. ShardingSphere's GeneratedKeysResultSet (the object you get from getGeneratedKeys()) exposes one synthesized numeric key column; LOB accessors are unimplemented because there is no large-object backing store behind the keys.
Source
Thrown at jdbc/src/main/java/org/apache/shardingsphere/driver/jdbc/unsupported/AbstractUnsupportedGeneratedKeysResultSet.java:192
@Override
public final int getFetchDirection() throws SQLException {
throw new SQLFeatureNotSupportedException("getFetchDirection");
}
@Override
public final void setFetchSize(final int rows) throws SQLException {
throw new SQLFeatureNotSupportedException("setFetchSize");
}
@Override
public final int getFetchSize() throws SQLException {
throw new SQLFeatureNotSupportedException("getFetchSize");
}
@Override
public final Blob getBlob(final int columnIndex) throws SQLException {
throw new SQLFeatureNotSupportedException("getBlob");
}
@Override
public final Blob getBlob(final String columnLabel) throws SQLException {
throw new SQLFeatureNotSupportedException("getBlob");
}
@Override
public final Clob getClob(final int columnIndex) throws SQLException {
throw new SQLFeatureNotSupportedException("getClob");
}
@Override
public final Clob getClob(final String columnLabel) throws SQLException {
throw new SQLFeatureNotSupportedException("getClob");
}
@OverrideView on GitHub (pinned to e952770a21)
Solutions
- Use getLong(1)/getObject(1) to read the generated key.
- Ensure LOB type handlers only run against SELECT result sets, not generated-keys result sets.
- If you truly need a BLOB, fetch it with a subsequent SELECT on the returned key.
- In unmodifiable third-party code, catch SQLFeatureNotSupportedException and retry with getObject(1).
Example fix
// before Blob b = keys.getBlob(1); // after long id = keys.getLong(1);
Defensive patterns
Strategy: try-catch
Validate before calling
int type = keys.getMetaData().getColumnType(1);
if (type == Types.BIGINT || type == Types.INTEGER) { long id = keys.getLong(1); } Type guard
private static boolean isGeneratedKeysRs(ResultSet rs) {
return rs.getClass().getName().endsWith("GeneratedKeysResultSet");
} Try / catch
try {
Blob b = rs.getBlob(1);
} catch (SQLFeatureNotSupportedException e) {
Object key = rs.getObject(1);
} Prevention
- Enable LOB type handlers only for SELECT result sets.
- Fetch BLOBs with a follow-up SELECT using the generated key.
- Use getObject in generic column readers.
When it happens
Trigger: Calling resultSet.getBlob(1) on the keys ResultSet — typically a generic mapper that selects getBlob when metadata or heuristics suggest binary data, or copy tools that try LOB accessors first for any column.
Common situations: ORM type handlers (old Hibernate BlobType) applied uniformly to all result sets; ResultSet->ResultSet copying utilities; code that assumed MySQL Connector/J behavior (which would throw or return null differently) after moving to ShardingSphere-JDBC for sharding.
Related errors
AI-assisted analysis of apache/shardingsphere@e952770a21 (2026-08-14).
Data as JSON: /api/errors/d4253fae3c019cc7.
Report an issue: GitHub.