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

  1. Use per-table extraction: getTable(catalog, schema, table).getPrimaryKey() instead of the namespace-wide call.
  2. If you own the extractor/dialect, implement the bulk query path and make supportsBulkPrimaryKeyRetrieval() return true.
  3. 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

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


AI-assisted analysis of hibernate/hibernate-orm@fad1729dce (2026-08-22). Data as JSON: /api/errors/34d6638a4d698419. Report an issue: GitHub.