hibernate/hibernate-orm · error · UnsupportedOperationException
Database doesn't support extracting all primary keys at once
Error message
Database doesn't support extracting all primary keys at once
What it means
InformationExtractor#getPrimaryKeys(Identifier, Identifier) is the namespace-wide (bulk) primary-key retrieval entry point, guarded by supportsBulkPrimaryKeyRetrieval(). When the active extractor/dialect cannot fetch all primary keys in a single query, calling it throws UnsupportedOperationException — the data must instead be requested table by table.
Source
Thrown at hibernate-core/src/main/java/org/hibernate/tool/schema/extract/internal/AbstractInformationExtractorImpl.java:982
// we did not find any results (no pk)
return null;
}
else {
// validate column list is properly contiguous
for ( int i = 0; i < columns.size(); i++ ) {
if ( columns.get( i ) == null ) {
throw new SchemaExtractionException( "Primary Key information was missing for KEY_SEQ = " + ( i+1) );
}
}
// build the return
return new PrimaryKeyInformationImpl( primaryKeyIdentifier, columns );
}
}
@Override
public NameSpacePrimaryKeysInformation getPrimaryKeys(Identifier catalog, Identifier schema) {
if ( !supportsBulkPrimaryKeyRetrieval() ) {
throw new UnsupportedOperationException( "Database doesn't support extracting all primary keys at once" );
}
else {
try {
return processPrimaryKeysResultSet(
catalog == null ? "" : catalog.getText(),
schema == null ? "" : schema.getText(),
(String) null,
this::extractNameSpacePrimaryKeysInformation
);
}
catch (SQLException e) {
throw convertSQLException( e,
"Error while reading primary key meta data for namespace "
+ new Namespace.Name( catalog, schema ) );
}
}
}
View on GitHub (pinned to fad1729dce)
Solutions
- Use per-table extraction: getTable(catalog, schema, table).getPrimaryKey() instead of the namespace-wide call.
- If you own the extractor/dialect, implement the bulk query path and make supportsBulkPrimaryKeyRetrieval() return true.
- Catch UnsupportedOperationException and fall back to iterating tables individually.
Example fix
// before
NameSpacePrimaryKeysInformation all = extractor.getPrimaryKeys(catalog, schema); // may throw
// after
NameSpacePrimaryKeysInformation all;
try {
all = extractor.getPrimaryKeys(catalog, schema);
} catch (UnsupportedOperationException e) {
all = null; // degrade to per-table retrieval
for (TableInformation t : extractor.getTables(catalog, schema, null)) {
t.getPrimaryKey();
}
} Defensive patterns
Strategy: fallback
Try / catch
NameSpacePrimaryKeysInformation all;
try {
all = extractor.getPrimaryKeys(catalog, schema);
} catch (UnsupportedOperationException e) {
all = null; // bulk not supported — fall back to per-table retrieval
for (TableInformation t : extractor.getTables(catalog, schema, null)) {
t.getPrimaryKey();
}
} Prevention
- Prefer per-table extraction APIs when targeting multiple databases.
- Check supportsBulkPrimaryKeyRetrieval() (or document the dialect's bulk capabilities) before namespace-wide calls.
- Wrap namespace-wide extraction behind a helper that degrades to per-table mode.
When it happens
Trigger: Schema tooling or user code calling getPrimaryKeys(catalog, schema) for a whole namespace while the active dialect/extractor reports supportsBulkPrimaryKeyRetrieval() == false (custom dialects overriding bulk support, or databases without a grouped PK metadata query).
Common situations: Custom InformationExtractor/Dialect implementations; namespace-wide schema management (grouped extraction) run against databases whose bulk queries are unavailable; reverse-engineering tools iterating whole schemas.
Related errors
- Database doesn't support extracting all indexes at once
- Database doesn't support extracting all foreign keys at once
- No add primary key syntax supported by SQLiteDialect
- SingleStore does not support altering primary key.
- Dialect does not support structured array types: ${dialectCl
AI-assisted analysis of hibernate/hibernate-orm@fad1729dce (2026-08-22).
Data as JSON: /api/errors/34d6638a4d698419.
Report an issue: GitHub.