hibernate/hibernate-orm · error · UnsupportedOperationException

"No current schema syntax supported by " + getClass().getNam

Error message

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

What it means

SpannerDialect.getCurrentSchemaCommand() unconditionally throws UnsupportedOperationException because Cloud Spanner has no 'current schema' query (no INFORMATION_SCHEMA-based SELECT for the current namespace, no DATABASE() equivalent acceptable here). Hibernate calls it when schema tooling or session code needs to resolve the current schema — note the companion getSchemaNameResolver() returns a resolver that yields "" instead. Hitting it usually means some component bypassed the resolver and directly asked the dialect for the current-schema SQL.

Source

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

	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;
	}

	@Override
	public String getAddPrimaryKeyConstraintString(String constraintName) {
		throw new UnsupportedOperationException( "Cannot add primary key constraint in Cloud Spanner." );
	}

View on GitHub (pinned to fad1729dce)

Solutions

  1. Use dialect.getSchemaNameResolver() instead — SpannerDialect supplies one that returns the empty string, so no SQL is issued.
  2. Treat the Spanner database as the only namespace: drop per-schema switching logic and key isolation off the database/connection URL.
  3. Branch custom tooling on dialect capability (e.g. `dialect instanceof SpannerDialect`) and skip current-schema resolution for Spanner.
  4. If a value is required for logging, hardcode "" to match the dialect's resolver.

Example fix

// before
String sql = dialect.getCurrentSchemaCommand()[0];
String schema = jdbcTemplate.queryForObject(sql, String.class);

// after
SchemaNameResolver resolver = dialect.getSchemaNameResolver();
String schema = resolver.resolveSchemaName(connection, dialect); // "" on Spanner
Defensive patterns

Strategy: fallback

Validate before calling

if (dialect instanceof SpannerDialect) {
  currentSchema = ""; // Spanner has no schemas; resolver returns ""
} else {
  currentSchema = dialect.getSchemaNameResolver().resolveSchemaName(conn, dialect);
}

Try / catch

try {
  sql = dialect.getCurrentSchemaCommand()[0];
} catch (UnsupportedOperationException e) {
  currentSchema = ""; // acceptable fallback: matches SpannerDialect's own resolver
}

Prevention

When it happens

Trigger: Code that calls dialect.getCurrentSchemaCommand() directly (e.g. custom SchemaMigrator/GroupSchemaNameResolver implementations, or tooling that executes the returned SQL), or Hibernate schema-management paths that request current-schema DDL while operating against SpannerDialect instead of using getSchemaNameResolver().

Common situations: Custom migration utilities written against other dialects (PostgreSQL `select current_schema()`) reused on Spanner; multi-tenant connection providers that switch and verify schemas per tenant; older Hibernate tooling versions that queried current schema during export.

Related errors


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