hibernate/hibernate-orm · error · UnsupportedOperationException

No drop foreign key syntax supported by SQLiteDialect

Error message

No drop foreign key syntax supported by SQLiteDialect

What it means

getDropForeignKeyString() on SQLiteDialect unconditionally throws because SQLite has no ALTER TABLE ... DROP FOREIGN KEY syntax: foreign keys can only be declared inline in CREATE TABLE. Hibernate's schema migrator reaches this method when it must drop an FK constraint during hbm2ddl update/drop processing. The dialect also reports dropConstraints() == false, so well-behaved tooling should skip the call entirely; hitting it usually means automatic schema management is being forced onto SQLite.

Source

Thrown at hibernate-community-dialects/src/main/java/org/hibernate/community/dialect/SQLiteDialect.java:497

	@Override
	public boolean hasAlterTable() {
		// As specified in NHibernate dialect
		return false;
	}

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

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

	@Override
	public String getDropForeignKeyString() {
		throw new UnsupportedOperationException( "No drop foreign key syntax supported by SQLiteDialect" );
	}

	@Override
	public String getAddForeignKeyConstraintString(
			String constraintName,
			String[] foreignKey,
			String referencedTable,
			String[] primaryKey,
			boolean referencesPrimaryKey) {
		throw new UnsupportedOperationException( "No add foreign key syntax supported by SQLiteDialect" );
	}

	@Override
	public String getAddPrimaryKeyConstraintString(String constraintName) {
		throw new UnsupportedOperationException( "No add primary key syntax supported by SQLiteDialect" );
	}

	@Override

View on GitHub (pinned to fad1729dce)

Solutions

1. Manage the SQLite schema with versioned migrations (Flyway/Liquibase) and set hibernate.hbm2ddl.auto=none
2. To change FKs, recreate the table using SQLite's documented ALTER recipe: create new table with correct CREATE TABLE, copy data, drop old, rename
3. Declare FKs inline via @ManyToOne/@JoinColumn so they are correct at initial table creation and never need an ALTER
4. In custom tooling, check dialect.dropConstraints() before requesting drop-FK SQL

Example fix

// before - auto schema management on SQLite tries DROP FOREIGN KEY
// hibernate.hbm2ddl.auto = update

// after - explicit migration only
// hibernate.hbm2ddl.auto = none
// V2__recreate_order.sql:
// CREATE TABLE order_new (... REFERENCES customer(id));
// INSERT INTO order_new SELECT * FROM order;
// DROP TABLE order;
// ALTER TABLE order_new RENAME TO order;

Dialect dialect = sessionFactory.getJdbcServices().getDialect();
if (dialect.dropConstraints()) {
    ddl.add(dialect.getDropForeignKeyString());
}
// SQLite reports dropConstraints() == false: skip drop-FK DDL instead of throwing

When it happens

Trigger: Running SchemaUpdate or SchemaExport drop (hibernate.hbm2ddl.auto=update/create-drop) over mappings whose FK constraints change or must be dropped; custom DDL utilities that ask every dialect for drop-foreign-key SQL.

Common situations: Entity model changed (removed or renamed @ManyToOne) while auto-DDL runs against a SQLite file or in-memory test database; a shared schema-management utility treats all dialects alike; migrating an app from MySQL to SQLite without changing DDL strategy.

Related errors

• No add foreign key syntax supported by SQLiteDialect
• No add primary key syntax supported by SQLiteDialect
• SingleStore does not support foreign keys and referential in
• SingleStore does not support foreign keys and referential in
• SingleStore does not support altering primary key.

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