hibernate/hibernate-orm · error · UnsupportedOperationException

Database doesn't support extracting all foreign keys at once

Error message

Database doesn't support extracting all foreign keys at once

What it means

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

Source

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

			}
		}
		catch (SQLException e) {
			throw convertSQLException( e,
					"Error accessing column metadata: "
							+ tableInformation.getName() );
		}

		final List<ForeignKeyInformation> foreignKeys = new ArrayList<>( builders.size() );
		for ( var foreignKeyBuilder : builders.values() ) {
			foreignKeys.add( foreignKeyBuilder.build() );
		}
		return foreignKeys;
	}

	@Override
	public NameSpaceForeignKeysInformation getForeignKeys(Identifier catalog, Identifier schema) {
		if ( !supportsBulkForeignKeyRetrieval() ) {
			throw new UnsupportedOperationException( "Database doesn't support extracting all foreign keys at once" );
		}
		else {
			try {
				return processImportedKeysResultSet(
						catalog == null ? "" : catalog.getText(),
						schema == null ? "" : schema.getText(),
						null,
						this::extractNameSpaceForeignKeysInformation
				);
			}
			catch (SQLException e) {
				throw convertSQLException( e,
						"Error while reading foreign key information for namespace "
						+ new Namespace.Name( catalog, schema ) );
			}
		}
	}

View on GitHub (pinned to fad1729dce)

Solutions

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

Example fix

// before
NameSpaceForeignKeysInformation all = extractor.getForeignKeys(catalog, schema); // may throw

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

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

When it happens

Trigger: Calling extractor.getForeignKeys(catalog, schema) for a whole namespace while the active extractor reports supportsBulkForeignKeyRetrieval() == false — custom dialect/extractor overrides, or tooling performing namespace-wide FK 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 imported-keys query.

Related errors

• Database doesn't support extracting all primary keys at once
• Database doesn't support extracting all indexes at once
• No drop foreign key syntax supported by SQLiteDialect
• No add foreign key syntax supported by SQLiteDialect
• SingleStore does not support foreign keys and referential in

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