hibernate/hibernate-orm · error · UnsupportedOperationException

Database doesn't support extracting all indexes at once

Error message

Database doesn't support extracting all indexes at once

What it means

InformationExtractor#getIndexes(Identifier, Identifier) is the namespace-wide (bulk) index retrieval entry point, guarded by supportsBulkIndexRetrieval(). When the active extractor/dialect cannot fetch all indexes in one query, calling it throws UnsupportedOperationException — indexes must then be fetched table by table.

Source

Thrown at hibernate-core/src/main/java/org/hibernate/tool/schema/extract/internal/AbstractInformationExtractorImpl.java:1216

	private static IndexInformationImpl.Builder indexInformationBuilder(
			Map<Identifier, IndexInformationImpl.Builder> builders,
			Identifier indexIdentifier) {
		final var builder = builders.get( indexIdentifier );
		if ( builder == null ) {
			final var newBuilder = IndexInformationImpl.builder( indexIdentifier );
			builders.put( indexIdentifier, newBuilder );
			return newBuilder;
		}
		else {
			return builder;
		}
	}

	@Override
	public NameSpaceIndexesInformation getIndexes(Identifier catalog, Identifier schema) {
		if ( !supportsBulkIndexRetrieval() ) {
			throw new UnsupportedOperationException( "Database doesn't support extracting all indexes at once" );
		}
		else {
			try {
				return processIndexInfoResultSet(
						catalog == null ? "" : catalog.getText(),
						schema == null ? "" : schema.getText(),
						null,
						false,
						true,
						this::extractNameSpaceIndexesInformation
				);
			}
			catch (SQLException e) {
				throw convertSQLException( e,
						"Error while reading index information for namespace "
						+ new Namespace.Name( catalog, schema ) );
			}
		}

View on GitHub (pinned to fad1729dce)

Solutions

1. Fetch per table: getTable(catalog, schema, table).getIndexes() instead of the namespace-wide call.
2. If you own the extractor, implement the bulk index path and make supportsBulkIndexRetrieval() return true.
3. Catch UnsupportedOperationException and degrade to per-table iteration.

Example fix

// before
NameSpaceIndexesInformation all = extractor.getIndexes(catalog, schema); // may throw

// after
NameSpaceIndexesInformation all;
try {
    all = extractor.getIndexes(catalog, schema);
} catch (UnsupportedOperationException e) {
    all = null; // degrade to per-table retrieval
    for (TableInformation t : extractor.getTables(catalog, schema, null)) {
        t.getIndexes();
    }
}

NameSpaceIndexesInformation all;
try {
    all = extractor.getIndexes(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.getIndexes();
    }
}

When it happens

Trigger: Calling extractor.getIndexes(catalog, schema) for a whole namespace while the active extractor reports supportsBulkIndexRetrieval() == false — custom dialect/extractor overrides, or tooling performing namespace-wide index scans on such setups.

Common situations: Custom InformationExtractor implementations; reverse-engineering or schema-diff tools iterating whole schemas; grouped schema management on databases without a usable bulk index query.

Related errors

• Database doesn't support extracting all primary keys at once
• Database doesn't support extracting all foreign keys at once
• Dialect does not support structured array types: ${dialectCl
• Bags don't have indexes :
• Bags don't have indexes

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