DDC-2703: UnitOfWork should not compute the change set on updated but not-persisted entities. #3384

New Issue

admin · 2026-01-22T14:19:02+01:00

admin commented

2026-01-22 14:19:02 +01:00

Originally created by @doctrinebot on GitHub (Sep 24, 2013).

Originally assigned to: @guilhermeblanco on GitHub.

Jira issue originally created by user shiroyuki:

Problem:
UnitOfWork computes the change set on updated but not-persisted entities.

How to reproduce:

Suppose I have 2 entities of class Node stored on the database of choices.
Load the entities via the respective repository (to ensure that the unit of work manages them).
Update something on both entities.
Only store one of them.

Expectation:

Any changes on the entity which is not persisted must not be stored in the database.

Actual Result:

The changes are saved.

Use the example:

Clone the demo app from git@github.com:shiroyuki/trphp13-demo.git.
Run the preparation commands to create the database (one DB called "trphp13"), schema (one table called "product") and load fixtures (3 entities).
Run app/console sandbox:case0 to recreate the bug.

Note:

I traced the bug down to computeChangeSet and it seems that even though the entity is not scheduled for dirty checks, the unit of work still computes the change set of the problematic entity. From the provided example, the node named "Node 2" should not be updated to "B" when the CaseZero command is executed.

Originally created by @doctrinebot on GitHub (Sep 24, 2013). Originally assigned to: @guilhermeblanco on GitHub. Jira issue originally created by user shiroyuki: **Problem:** UnitOfWork computes the change set on updated but not-persisted entities. **How to reproduce:** 1. Suppose I have 2 entities of class Node stored on the database of choices. 2. Load the entities via the respective repository (to ensure that the unit of work manages them). 3. Update something on both entities. 4. Only store one of them. **Expectation:** Any changes on the entity which is not persisted must not be stored in the database. **Actual Result:** The changes are saved. **Use the example:** 1. Clone the demo app from **git@github.com:shiroyuki/trphp13-demo.git**. 2. Run the preparation commands to create the database (one DB called "trphp13"), schema (one table called "product") and load fixtures (3 entities). 3. Run `app/console sandbox:case0` to recreate the bug. **Note:** I traced the bug down to `computeChangeSet` and it seems that even though the entity is not scheduled for dirty checks, the unit of work still computes the change set of the problematic entity. From the provided example, the node named "Node 2" should not be updated to "B" when the CaseZero command is executed.

admin added the Bug label 2026-01-22 14:19:02 +01:00

admin closed this issue

2026-01-22 14:19:02 +01:00

admin commented

2026-01-22 14:19:02 +01:00

@doctrinebot commented on GitHub (Sep 24, 2013):

Comment created by @ocramius:

[~shiroyuki] we are not going to checkout your project for this. Please make a small example that uses ONLY the ORM, with no other involved frameworks.

You should be able to do that in a single php script that includes:

the involved entities
an initialization of the ORM
the functional example

we can then convert that into a unit test once it has been verified.

@doctrinebot commented on GitHub (Sep 24, 2013): Comment created by @ocramius: [~shiroyuki] we are not going to checkout your project for this. Please make a small example that uses ONLY the ORM, with no other involved frameworks. You should be able to do that in a single php script that includes: 1) the involved entities 2) an initialization of the ORM 3) the functional example we can then convert that into a unit test once it has been verified.

admin commented

2026-01-22 14:19:02 +01:00

@doctrinebot commented on GitHub (Sep 24, 2013):

Comment created by @guilhermeblanco:

This should be related to change tracking policy.
Doctrine uses IMPLICIT change tracking policy by default, applying an algorithm called persist-by-reachability.
To fix your issue, you need to modify your change tracking to DEFERRED_EXPLICIT or NOTIFY.

Here is a more detailed explanation:

So the change you need to do is: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/change-tracking-policies.html

/****
 * @ORM\Entity
 * @ORM\ChangeTrackingPolicy("DEFERRED_EXPLICIT")
 */
class Node
{
    // ...
}

@doctrinebot commented on GitHub (Sep 24, 2013): Comment created by @guilhermeblanco: This should be related to change tracking policy. Doctrine uses IMPLICIT change tracking policy by default, applying an algorithm called persist-by-reachability. To fix your issue, you need to modify your change tracking to DEFERRED_EXPLICIT or NOTIFY. Here is a more detailed explanation: So the change you need to do is: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/change-tracking-policies.html ``` /**** * @ORM\Entity * @ORM\ChangeTrackingPolicy("DEFERRED_EXPLICIT") */ class Node { // ... } ```

admin commented

2026-01-22 14:19:03 +01:00

@doctrinebot commented on GitHub (Sep 24, 2013):

Comment created by @guilhermeblanco:

It's an issue of misunderstanding change tracking policies.

@doctrinebot commented on GitHub (Sep 24, 2013): Comment created by @guilhermeblanco: It's an issue of misunderstanding change tracking policies.

admin commented

2026-01-22 14:19:03 +01:00

@doctrinebot commented on GitHub (Sep 24, 2013):

Issue was closed with resolution "Invalid"

@doctrinebot commented on GitHub (Sep 24, 2013): Issue was closed with resolution "Invalid"

admin commented

2026-01-22 14:19:04 +01:00

@doctrinebot commented on GitHub (Sep 24, 2013):

Comment created by shiroyuki:

Thank you. :D

@doctrinebot commented on GitHub (Sep 24, 2013): Comment created by shiroyuki: Thank you. :D

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#3384