#12549·orm

Unnamed Foreign Keys not longer has a shortened hashed name and run into error

Author: alexander-schranzCreated Aug 6, 2026Updated Aug 8, 2026

Bug Report

Q A
Version 3.7.x-dev (d536aced)
Previous Version if the bug is a regression 3.6.7

Summary

We previously did run into the existing Schema issue https://github.com/doctrine/orm/issues/12547 after the fixes where merged our CI running on composer config minimum-stability dev still fails with unexpected error.

Current behavior

In Connection.php line 27:
                                                                               
  SQLSTATE[42000]: Syntax error or access violation: 1059 Identifier name
  'sn_snippet_dimension_content_excerpt_audience_target_groups_ibfk_1' is
  too long

mostly related to https://github.com/doctrine/orm/pull/12528 "Avoid adding then dropping FK constraints" changes

Expected behavior

Foreign Keys are this in current DB:

Image Image

How to reproduce

bash
git clone [email protected]:sulu/sulu.git reproducer-dc-fkn
cd reproducer-dc-fkn
composer config minimum-stability dev
composer update

docker compose up

bin/console doctrine:schema:update --force
Some claude findings

The remaining failure has a different cause. Since #12528 ("Avoid adding then dropping FK constraints", commit d4dc7681), SchemaTool adds association foreign keys through the DBAL Schema::edit() / TableEditor API and no longer passes a constraint name:

php
// src/Tools/SchemaTool.php
if (method_exists(Schema::class, 'edit')) {
    $schema = $schema->edit()->modifyTable(
        $fkData['table']->getObjectName(),
        static function (TableEditor $tableEditor) use ($fkData): void {
            $tableEditor->addForeignKeyConstraint(new ForeignKeyConstraint(
                localColumnNames: $fkData['localColumns'],
                foreignTableName: $fkData['foreignTableName'],
                foreignColumnNames: $fkData['foreignColumns'],
                options: $fkData['fkOptions'],
                // no `name:` argument -> constraint is emitted unnamed
            ));
        },
    )->create();
} else {
    // still names the constraint via Table::_generateIdentifierName(..., 'fk', $maxIdentifierLength)
    $fkData['table']->addForeignKeyConstraint(
        $fkData['foreignTableName'],
        $fkData['localColumns'],
        $fkData['foreignColumns'],
        $fkData['fkOptions'],
    );
}

Before #12528 this code path unconditionally called Table::addForeignKeyConstraint(), which fills in a generated FK_ name truncated to the platform's maximum identifier length. Now that name is dropped and the database is left to invent one.

Schema::edit() only exists on doctrine/dbal 4.5.x-dev, so the bug is invisible on released DBAL versions — on 4.4.x the else branch keeps working. It reproduces with doctrine/orm 3.7.x-dev + doctrine/dbal 4.5.x-dev.

On MySQL, an unnamed constraint is auto-named

ibfk, which is 7 characters longer than the table name. Any table name longer than 57 characters therefore exceeds the 64 character identifier limit and doctrine:schema:create aborts.

Current behavior

In Connection.php line 27:

  SQLSTATE[42000]: Syntax error or access violation: 1059 Identifier name 'sn
  _snippet_dimension_content_excerpt_audience_target_groups_ibfk_1' is too lo
  ng

SchemaTool emits every association foreign key without a constraint name:

ALTER TABLE sn_snippet_dimension_content_excerpt_audience_target_groups ADD FOREIGN KEY (snippet_dimension_content_id) REFERENCES sn_snippet_dimension_contents (id) ON DELETE CASCADE; ALTER TABLE sn_snippet_dimension_content_excerpt_audience_target_groups ADD FOREIGN KEY (target_group_id) REFERENCES at_target_groups (id) ON DELETE CASCADE;

In our application this affects all 165 foreign keys of the schema — getCreateSchemaSql() returns 165 ADD FOREIGN KEY and 0 ADD CONSTRAINT statements.

Besides the hard failure above, this also changes the constraint names for every schema created on DBAL 4.5: databases created previously carry FK_ names while newly created ones carry

ibfk, which makes doctrine:migrations:diff and doctrine:schema:update produce spurious drop/recreate statements against existing databases.

Expected behavior

SchemaTool should keep naming the constraints as it did before #12528, so that the generated SQL stays identical across DBAL versions and stays within the platform's identifier length limit:

sql
ALTER TABLE sn_snippet_dimension_content_excerpt_audience_target_groups ADD CONSTRAINT FK_87109F587891499D FOREIGN KEY (snippet_dimension_content_id) REFERENCES sn_snippet_dimension_contents (id) ON DELETE CASCADE;
ALTER TABLE sn_snippet_dimension_content_excerpt_audience_target_groups ADD CONSTRAINT FK_87109F5824FF092E FOREIGN KEY
(target_group_id) REFERENCES at_target_groups (id) ON DELETE CASCADE;