hibernate/hibernate-orm · error · UnsupportedOperationException

No add foreign key syntax supported by SQLiteDialect

Error message

No add foreign key syntax supported by SQLiteDialect

What it means

getAddForeignKeyConstraintString(...) on SQLiteDialect unconditionally throws because SQLite cannot add a foreign key constraint with ALTER TABLE; FK constraints exist only as table constraints inside CREATE TABLE. Hibernate's schema migrator hits this method when, during hbm2ddl update, it wants to emit ALTER TABLE ADD CONSTRAINT for a new or changed association. The correct model on SQLite is to define the FK inline when the table is first created.

Source

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

	@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
	public boolean supportsCommentOn() {
		return true;
	}

	@Override
	public boolean supportsIfExistsBeforeTableName() {
		return true;
	}

	@Override

View on GitHub (pinned to fad1729dce)

Solutions

1. Recreate the table with the FK inline in CREATE TABLE via a migration script (copy, drop, rename)
2. Keep associations in mappings so the FK is present from the initial CREATE TABLE and never needs an ALTER
3. Switch hibernate.hbm2ddl.auto to none (or validate) and manage DDL with Flyway/Liquibase
4. If generating DDL programmatically, skip ALTER-based constraint statements for SQLite

Example fix

// before - new association + auto-update => ALTER TABLE ADD CONSTRAINT (throws)
// hibernate.hbm2ddl.auto = update

// after - table created complete from day one
// hibernate.hbm2ddl.auto = create (fresh DB) or none + migration:
// CREATE TABLE orders (id integer primary key, customer_id integer REFERENCES customer(id));

static boolean supportsAlterConstraints(Dialect d) {
    return d.hasAlterTable() && !(d instanceof SQLiteDialect);
}

// in DDL generation:
if (supportsAlterConstraints(dialect)) {
    ddl.add(dialect.getAddForeignKeyConstraintString(name, fk, table, pk, true));
} else {
    log.warn('dialect requires FKs inline in CREATE TABLE; emit a table rebuild migration');
}

When it happens

Trigger: Adding a new @ManyToOne/@OneToMany association to an entity while hibernate.hbm2ddl.auto=update runs against an existing SQLite table; SchemaExport update flows over changed mappings; generic DDL generators that emit add-constraint statements for every dialect.

Common situations: Iterating on an entity model with auto-DDL enabled in SQLite-based desktop/mobile/embedded apps; test suites that use SQLite in-memory with ddl-auto=update; porting a MySQL schema workflow to SQLite.

Related errors

• No drop 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/f9c74e2a71dd781a. Report an issue: GitHub.