hibernate/hibernate-orm · error · UnsupportedOperationException

"No drop schema syntax supported by " + getClass().getName()

Error message

"No drop schema syntax supported by " + getClass().getName()

What it means

SpannerDialect.getDropSchemaCommand() unconditionally throws UnsupportedOperationException because Cloud Spanner has no DROP SCHEMA statement (the dialect declares canCreateSchema()=false and Spanner has no schema concept). Hibernate invokes this method when schema-drop tooling (SchemaExport.drop(), hbm2ddl.auto=drop/create-drop) encounters a mapped schema/namespace name. Hitting it means your mappings or tooling requested schema-level DDL that Spanner cannot express.

Source

Thrown at hibernate-core/src/main/java/org/hibernate/dialect/SpannerDialect.java:1192

	@Override
	public GenerationType getNativeValueGenerationStrategy() {
		return GenerationType.SEQUENCE;
	}

	@Override
	public boolean canCreateSchema() {
		return false;
	}

	@Override
	public String[] getCreateSchemaCommand(String schemaName) {
		throw new UnsupportedOperationException(
				"No create schema syntax supported by " + getClass().getName() );
	}

	@Override
	public String[] getDropSchemaCommand(String schemaName) {
		throw new UnsupportedOperationException(
				"No drop schema syntax supported by " + getClass().getName() );
	}

	@Override
	public String getCurrentSchemaCommand() {
		throw new UnsupportedOperationException(
				"No current schema syntax supported by " + getClass().getName() );
	}

	@Override
	public SchemaNameResolver getSchemaNameResolver() {
		// Spanner does not have a notion of database name schemas, so return "".
		return (connection, dialect) -> "";
	}

	@Override
	public boolean qualifyIndexName() {
		return false;

View on GitHub (pinned to fad1729dce)

Solutions

1. Remove schema names from entity mappings (@Table schema/catalog attributes) so drop tooling never asks for schema DDL.
2. Use hibernate.hbm2ddl.auto=none or create-only and manage Spanner DDL with the Cloud Spanner migration tool / client library DDL APIs.
3. Guard programmatic drops with `if (dialect.canCreateSchema())` before requesting schema-level commands.
4. Drop/recreate the whole Spanner database in test harnesses instead of per-schema drops.

Example fix

// before
spring.jpa.hibernate.ddl-auto=create-drop
// with @Table(name="orders", schema="sales")

// after
spring.jpa.hibernate.ddl-auto=none
// @Table(name="orders") — no schema attribute

if (dialect.canCreateSchema()) {
  new SchemaExport(cfg).drop(target, output);
} else {
  // Spanner: drop tables via explicit DDL, never schema-level commands
}

try {
  export.drop(target, outputFile);
} catch (UnsupportedOperationException e) {
  if (e.getMessage().contains("drop schema")) { /* skip schema drop; drop tables individually */ }
  throw e;
}

When it happens

Trigger: Running `new SchemaExport().drop(...)` or setting hibernate.hbm2ddl.auto=drop/create-drop while an entity maps @Table(schema=...) or the naming strategy emits a schema, on a Spanner connection; the drop phase asks the dialect for DROP SCHEMA DDL first.

Common situations: Test teardown with create-drop on the Spanner emulator; shutting down Spring Boot apps that register a schema-generation drop script; porting a multi-schema PostgreSQL application where teardown drops each schema.

Related errors

• "No create schema syntax supported by " + getClass().getName
• Cannot add primary key constraint in Cloud Spanner.
• "No current schema syntax supported by " + getClass().getNam
• No type mapping for org.hibernate.type.SqlTypes code: %s (%s
• No create schema syntax supported by " + getClass().getName(

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