DDC-3017: UnitOfWork::$entityIdentifiers does not get updated when saving composite PK with a JoinColum as PK #3748

Closed
opened 2026-01-22 14:27:12 +01:00 by admin · 6 comments
Owner

Originally created by @doctrinebot on GitHub (Mar 8, 2014).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user rande:

The Sonata Admin Bundle rely on the UnitOfWork::getEntityIdentifier method to retrieve the object identifier.

We are adding support for composite PK with a FK as described in the gist: https://gist.github.com/rande/9439778 .

The bug occurs when the Material reference is updated on the Color object. The Color has a new set of PK. However the UnitOfWork::$entityIdentifiers is not updated when the object is persisted. So the values stored UnitOfWork::$entityIdentifiers are invalid for the Color object.

The consequence is that we are unable to redirect the user once the object is saved as the UnitOfWork::getEntityIdentifier refers to the old values.

Originally created by @doctrinebot on GitHub (Mar 8, 2014). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user rande: The Sonata Admin Bundle rely on the `UnitOfWork::getEntityIdentifier` method to retrieve the object identifier. We are adding support for composite PK with a FK as described in the gist: https://gist.github.com/rande/9439778 . The bug occurs when the Material reference is updated on the Color object. The Color has a new set of PK. However the UnitOfWork::$entityIdentifiers is not updated when the object is persisted. So the values stored `UnitOfWork::$entityIdentifiers` are invalid for the Color object. The consequence is that we are unable to redirect the user once the object is saved as the UnitOfWork::getEntityIdentifier refers to the old values.
admin added the Bug label 2026-01-22 14:27:12 +01:00
admin closed this issue 2026-01-22 14:27:12 +01:00
Author
Owner

@doctrinebot commented on GitHub (Mar 12, 2014):

Comment created by @ocramius:

[~rande] can you please come up with a failing test case for this issue?

@doctrinebot commented on GitHub (Mar 12, 2014): Comment created by @ocramius: [~rande] can you please come up with a failing test case for this issue?
Author
Owner

@doctrinebot commented on GitHub (Mar 23, 2014):

Comment created by @beberlei:

It is not supported to change the identifier. They are assumed to be immutable by Doctrine and we cannot change that, as the consequences are impossible to handle.

@doctrinebot commented on GitHub (Mar 23, 2014): Comment created by @beberlei: It is not supported to change the identifier. They are assumed to be immutable by Doctrine and we cannot change that, as the consequences are impossible to handle.
Author
Owner

@doctrinebot commented on GitHub (Mar 23, 2014):

Issue was closed with resolution "Won't Fix"

@doctrinebot commented on GitHub (Mar 23, 2014): Issue was closed with resolution "Won't Fix"
Author
Owner

@doctrinebot commented on GitHub (Mar 31, 2014):

Comment created by rande:

Thanks for commenting this issue. So with composite keys the assumption is wrong and from your comment this bug is the expected behavior.

Now, should doctrine provide a secure method to retrieve the identifier keys ?

@doctrinebot commented on GitHub (Mar 31, 2014): Comment created by rande: Thanks for commenting this issue. So with composite keys the assumption is wrong and from your comment this bug is the expected behavior. Now, should doctrine provide a secure method to retrieve the identifier keys ?
Author
Owner

@doctrinebot commented on GitHub (Mar 31, 2014):

Comment created by @ocramius:

[~rande] shouldn't you extract identifiers via metadata by having an instance of an entity?

@doctrinebot commented on GitHub (Mar 31, 2014): Comment created by @ocramius: [~rande] shouldn't you extract identifiers via metadata by having an instance of an entity?
Author
Owner

@doctrinebot commented on GitHub (Mar 31, 2014):

Comment created by rande:

It is what I did: https://github.com/sonata-project/SonataDoctrineORMAdminBundle/blob/master/Model/ModelManager.php#L277-L303

However it will be better to have a clean implementation in the ORM.

@doctrinebot commented on GitHub (Mar 31, 2014): Comment created by rande: It is what I did: https://github.com/sonata-project/SonataDoctrineORMAdminBundle/blob/master/Model/ModelManager.php#L277-L303 However it will be better to have a clean implementation in the ORM.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#3748