Compare foreign key constraints by name - #7486
Merged
Merged
Conversation
Two foreign keys that differ only by name are two constraints, so the comparator reports one of them as dropped and the other as added.
greg0ire
approved these changes
Aug 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #7410
Currently, the schema comparator ignores the name of a foreign key constraint: two constraints on the same columns are equal, whatever they're called.
If the application defines a schema with an FK named
old_fk, deploys it to the database, then renames it tonew_fkand performs a migration, the FK in the database will remain namedold_fkwithout a diff reported.This way, the resulting schema in the database is defined not only by the application-defined schema, but also by the path taken to reach it. This behavior is quite counterintuitive and isn't typical for DBAL.
#6413 attempted to make this change before and was reverted in #6445 due to the issue reported in #6437. The fact that an upgrade to a patch release (3.8.5) started reporting a schema mismatch was considered a breaking change. The change itself was right, but it was made in the wrong release.
ORM Behavior Considerations
From #6437, it looks like the ORM generates the FK name based on the columns it covers, but its users don't expect a rename when the underlying columns change. This expectation directly contradicts the "deployed schema is a function of the application-defined schema" idea.
If the ORM wants to retain this behavior (which is quite questionable), it needs to maintain a stable FK identity (once created and named, it stays named that way forever). However, even a migration to this behavior may itself result in a schema change, which is exactly the issue it would attempt to solve.
The most natural way to handle this is to accept schema changes.
Consistency with #7477
#7477 makes the comparator diff unique constraints. That's new functionality, so it gets the behavior right from the start and compares them by name. Neither leaving the current FK name comparison logic as is, nor mimicking it in the new functionality looks right to me.