ArrayHydrator doesn't hydrate Many-To-One relations when relation is (part of) the primary key #4999

New Issue

admin · 2026-01-22T14:56:13+01:00

admin commented

2026-01-22 14:56:13 +01:00

Originally created by @InterEmotion on GitHub (Feb 2, 2016).

I'm investigating an upgrade from Doctrine 2.4.0 to 2.5.4. For performance reasons array hydration is used in a few cases. This worked fine/as expected in version 2.4.0. Since 2.4.1 it doesn't. It got changed becuse of this issue and commit: DDC-2759

Problem: the ArrayHydrator doesn't hydrate Many-To-One relations when the attribute is (part of) the primary key.

I have done a little digging into this and studied the ResultSetMapping data. I couldn't find anything to query without risking naming collisions. However, the association mapping that gets queried earlier in the hydration contains the conclusive information:

So by expanding the check in ArrayHydrator.php from:

} else if ( ! isset($baseElement[$relationAlias])) {
    $baseElement[$relationAlias] = $data;
}

to:

} else if ( 
    ( ! isset($baseElement[$relationAlias])) || 
    ($relation['fieldName'] == $relationAlias)) {
    $baseElement[$relationAlias] = $data;
}

The hydration works again as expected and won't give the regression issues from 2.4.0. I hope you can concur with my findings and solution, and adopt it.

Originally created by @InterEmotion on GitHub (Feb 2, 2016). I'm investigating an upgrade from Doctrine 2.4.0 to 2.5.4. For performance reasons array hydration is used in a few cases. This worked fine/as expected in version 2.4.0. Since 2.4.1 it doesn't. It got changed becuse of this issue and commit: [DDC-2759](https://github.com/doctrine/doctrine2/commit/1d2cd827069f1df77a67c4f850c9f476156957f2) Problem: the ArrayHydrator doesn't hydrate Many-To-One relations when the attribute is (part of) the primary key. I have done a little digging into this and studied the ResultSetMapping data. I couldn't find anything to query without risking naming collisions. However, the association mapping that gets queried earlier in the hydration contains the conclusive information: So by expanding the check in `ArrayHydrator.php` from: ``` php } else if ( ! isset($baseElement[$relationAlias])) { $baseElement[$relationAlias] = $data; } ``` to: ``` php } else if ( ( ! isset($baseElement[$relationAlias])) || ($relation['fieldName'] == $relationAlias)) { $baseElement[$relationAlias] = $data; } ``` The hydration works again as expected and won't give the regression issues from 2.4.0. I hope you can concur with my findings and solution, and adopt it.

admin closed this issue

2026-01-22 14:56:13 +01:00

admin commented

2026-01-22 14:56:14 +01:00

@Jean85 commented on GitHub (Feb 5, 2016):

Have you tried running the tests with this modification?

@Jean85 commented on GitHub (Feb 5, 2016): Have you tried running the tests with this modification?

admin commented

2026-01-22 14:56:14 +01:00

@InterEmotion commented on GitHub (Jun 17, 2016):

I sincerely apologize for my late reaction. I got pulled into other matters. The issue is still a problem for me though.

I have run the unittests with the modified code (master branch). It produced the following new failure:

Doctrine\Tests\ORM\Functional\Ticket\DDC2759Test::testCorrectNumberOfAssociationsIsReturned
Failed asserting that actual size 1 matches expected size 2.

C:\dev\Git\doctrine2\tests\Doctrine\Tests\ORM\Functional\Ticket\DDC2759Test.php:62

@InterEmotion commented on GitHub (Jun 17, 2016): I sincerely apologize for my late reaction. I got pulled into other matters. The issue is still a problem for me though. I have run the unittests with the modified code (master branch). It produced the following new failure: ``` Doctrine\Tests\ORM\Functional\Ticket\DDC2759Test::testCorrectNumberOfAssociationsIsReturned Failed asserting that actual size 1 matches expected size 2. C:\dev\Git\doctrine2\tests\Doctrine\Tests\ORM\Functional\Ticket\DDC2759Test.php:62 ```

admin commented

2026-01-22 14:56:15 +01:00

@InterEmotion commented on GitHub (Jun 21, 2016):

Again, my apologies. It turned out te be a naming collision. The name of the property was the same as that of the key. In my case, renaming the column to ****_id did the trick.

Can be closed.

@InterEmotion commented on GitHub (Jun 21, 2016): Again, my apologies. It turned out te be a naming collision. The name of the property was the same as that of the key. In my case, renaming the column to ****_id did the trick. Can be closed.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#4999