Add regression test for STI duplicate foreign key deduplication - #12391
Open
janedbal wants to merge 1 commit into
Open
Add regression test for STI duplicate foreign key deduplication#12391janedbal wants to merge 1 commit into
janedbal wants to merge 1 commit into
Conversation
Contributor
Author
|
Any chance somebody looks into this one? |
Member
|
It seems there are CI jobs failing. Please take a look at this guide for more on how to handle those. |
janedbal
force-pushed
the
fix/sti-duplicate-foreign-key-deprecation
branch
from
April 22, 2026 07:00
f750132 to
9a912d2
Compare
Contributor
Author
|
@greg0ire None of those were related to our changes. I just rebased to trigger new pipeline. |
Member
|
That's cool. Bear in mind that I will always prioritize reviewing PRs with a green build. |
greg0ire
reviewed
Apr 22, 2026
When multiple STI child entities have a ManyToOne relation to the same
target entity using the same join column, SchemaTool used to call
addForeignKeyConstraint twice with the same constraint name, triggering
a DBAL deprecation ("Overwriting an existing foreign key constraint").
The production fix landed in 3.6.x via doctrine#12477 ("Avoid adding the same
foreign key twice for STI") but shipped without a regression test. This
adds the missing coverage: the STI table must end up with exactly one
foreign key when children share the same join column.
See doctrine/dbal#7125
janedbal
force-pushed
the
fix/sti-duplicate-foreign-key-deprecation
branch
from
July 10, 2026 07:55
451f52b to
d9b04de
Compare
janedbal
changed the title
greg0ire
reviewed
Jul 10, 2026
| return false; | ||
| } | ||
|
|
||
| public function testSingleTableInheritanceWithSameForeignKeyInChildrenDoesNotTriggerDeprecation(): void |
Member
There was a problem hiding this comment.
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.
When multiple STI child entities have a
ManyToOnerelation to the same target entity using the same join column,SchemaToolcalledaddForeignKeyConstrainttwice with the same constraint name, triggering a DBAL deprecation ("Overwriting an existing foreign key constraint").The fix skips the redundant
addForeignKeyConstraintcall when an identical FK (same local columns, same foreign table, same foreign columns) was already added.See doctrine/dbal#7125
EDIT (after rebase): The production fix has since landed in
3.6.xvia #12477 ("Avoid adding the same foreign key twice for STI"), which implements the same deduplication more thoroughly (it also compares FK options). Rebasing dropped the now-redundantSchemaToolchange, so this PR now only adds the regression test — upstream merged the fix without one, and this test guards the STI same-join-column scenario going forward.