Embedded class not changed, but keeps being marked as changed in the EntityChangeset #5957

New Issue

admin · 2026-01-22T15:23:07+01:00

admin commented

2026-01-22 15:23:07 +01:00

Originally created by @michsk on GitHub (Apr 19, 2018).

SLC enabled
Entity with a Embedded class

I am not sure how to recreate this so suggestions are very welcome. My guess is it has to do with SLC.

Sometimes the Embedded class is marked as changed because it fails:

// skip if value haven't changed
if ($orgValue === $actualValue) {
    continue;
}

in the UnitOfWerk @695. But the strange thing is, nothing has changed in this embedded class. Other props in the parent have changed but nothing in the embedded class.

Because it is marked as changed, the Subscribers get triggered and more unexpected behavior happens. Like trying to commit "something" to the DB, but nothing changed. I can even see the blank transactions and commits in my SQL log:

==== 
Query: "START TRANSACTION"
Params: 

Types: 

==== 

==== 
Query: "COMMIT"
Params: 

Types: 

====

Now the annoying thing is that this keeps being marked as changed. So when i call for the entity another time in a new request and just flush the EM, it is again marked as changed (that's why i think SLC has something to do with this)

The second request:

$em = $this->app->getEntityManager();
$entity = $em->find(Account::class, $id);
$em->flush();

So because the Embedded class keeps being marked as changed, even the above lines keep triggering the Subscribers and keep making the empty DB commits.

After running, redis-cli flushall, everything is back to normal, but after some changes to the parent class, it sometimes unexpectedly again marks the embedded class as changed and the issue keeps persisting until flushall is called again.

Again, i am having a hard time to reproducing this but any suggestions would be appreciated.

Originally created by @michsk on GitHub (Apr 19, 2018). - SLC enabled - Entity with a Embedded class I am not sure how to recreate this so suggestions are very welcome. My guess is it has to do with SLC. Sometimes the Embedded class is marked as changed because it fails: ```php // skip if value haven't changed if ($orgValue === $actualValue) { continue; } ``` in the UnitOfWerk @695. But the strange thing is, nothing has changed in this embedded class. Other props in the parent have changed but nothing in the embedded class. Because it is marked as changed, the Subscribers get triggered and more unexpected behavior happens. Like trying to commit "something" to the DB, but nothing changed. I can even see the blank transactions and commits in my SQL log: ``` ==== Query: "START TRANSACTION" Params: Types: ==== ==== Query: "COMMIT" Params: Types: ==== ``` Now the annoying thing is that this keeps being marked as changed. So when i call for the entity another time in a new request and just flush the EM, it is again marked as changed (that's why i think SLC has something to do with this) The second request: ```php $em = $this->app->getEntityManager(); $entity = $em->find(Account::class, $id); $em->flush(); ``` So because the Embedded class keeps being marked as changed, even the above lines keep triggering the Subscribers and keep making the empty DB commits. After running, `redis-cli flushall`, everything is back to normal, but after some changes to the parent class, it sometimes unexpectedly again marks the embedded class as changed and the issue keeps persisting until flushall is called again. Again, i am having a hard time to reproducing this but any suggestions would be appreciated.

admin commented

2026-01-22 15:23:07 +01:00

@michsk commented on GitHub (Apr 19, 2018):

Ok, disabled the RedisCache in the ChainCache and only keeping the ArrayCache confirms that this has to do with the RedisCaching implementation. Looking further into it.

@michsk commented on GitHub (Apr 19, 2018): Ok, disabled the RedisCache in the ChainCache and only keeping the ArrayCache confirms that this has to do with the RedisCaching implementation. Looking further into it.

admin commented

2026-01-22 15:23:08 +01:00

@michsk commented on GitHub (Apr 19, 2018):

An interesting thing is that when this doesn't happen. And everything is changed as expected. Than in the UOW, in the computeChangeSet the $originalData does not contain the $users Embedded class, which is in the other cases faulty.

@michsk commented on GitHub (Apr 19, 2018): An interesting thing is that when this doesn't happen. And everything is changed as expected. Than in the UOW, in the `computeChangeSet` the `$originalData` does not contain the `$users` Embedded class, which is in the other cases faulty.

admin commented

2026-01-22 15:23:09 +01:00

@Ocramius commented on GitHub (Apr 19, 2018):

@Michal-sk this kind of stuff happens when you convert 1 to '1' or true (depending on DBAL types in use). I suggest checking the entity state against the embeddable state very carefully. If objects are involved, then please remember that object references are compared (https://stackoverflow.com/questions/15486402/doctrine2-orm-does-not-save-changes-to-a-datetime-field)

@Ocramius commented on GitHub (Apr 19, 2018): @Michal-sk this kind of stuff happens when you convert `1` to `'1'` or `true` (depending on DBAL types in use). I suggest checking the entity state against the embeddable state very carefully. If objects are involved, then please remember that object references are compared (https://stackoverflow.com/questions/15486402/doctrine2-orm-does-not-save-changes-to-a-datetime-field)

admin commented

2026-01-22 15:23:09 +01:00

@michsk commented on GitHub (Apr 20, 2018):

@Ocramius thanks for the heads up. The thing is tough. I'm really not expecting the Embedable to be in the changeSet. Because all the changes are in there represented property. So

Account (entity)
- Couple (Embeddable) (users)
-- Person (Embeddable) (person)
-- Partner (Embeddable) (partner)

When i do a change to for example the Persons name, i see in the change set: users.person.firstname. And this happens for basically all the changes. I get a string key (property / field) name and the arraty containing the IS and WAS values. But sometimes, for some reason, the users property is changed in the Account entity, instead of a concrete field.

@michsk commented on GitHub (Apr 20, 2018): @Ocramius thanks for the heads up. The thing is tough. I'm really not expecting the Embedable to be in the changeSet. Because all the changes are in there represented property. So ``` Account (entity) - Couple (Embeddable) (users) -- Person (Embeddable) (person) -- Partner (Embeddable) (partner) ``` When i do a change to for example the Persons name, i see in the change set: `users.person.firstname`. And this happens for basically all the changes. I get a string key (property / field) name and the arraty containing the IS and WAS values. But sometimes, for some reason, the users property is changed in the Account entity, instead of a concrete field.

admin commented

2026-01-22 15:23:09 +01:00

@michsk commented on GitHub (Apr 20, 2018):

Starting to think this might be somewhat related to using: https://github.com/marc-mabe/php-enum. Than when using the Serialize trait (https://github.com/marc-mabe/php-enum/issues/52), i think we might hit the issue here.

@michsk commented on GitHub (Apr 20, 2018): Starting to think this might be somewhat related to using: https://github.com/marc-mabe/php-enum. Than when using the Serialize trait (https://github.com/marc-mabe/php-enum/issues/52), i think we might hit the issue here.

admin commented

2026-01-22 15:23:09 +01:00

@uerka commented on GitHub (Dec 3, 2024):

I just appeared in similar situation with embedded entities, although it might have other reason.
I have doctrine onFlush listener that listens to changes in one entity (lets say ContactPerson) and if fields (for example name) in it changes - it changes some fields in related entity (lets say it called Company). The Company has also embedded entity Address , that is not changing.
In the end of listener - as suggested in documentation - i'm calling recomputeSingleEntityChangeSet for Company to get changes registered. But after doing that - i have address appearing in the changeSet, like it changed from null to actual object.
If i call computeChangeSet instead of recomputeSingleEntityChangeSet - changeSet looks as expected

doctrine/orm version 2.19 and 2.20 (tried on both)

@uerka commented on GitHub (Dec 3, 2024): I just appeared in similar situation with embedded entities, although it might have other reason. I have doctrine onFlush listener that listens to changes in one entity (lets say ContactPerson) and if fields (for example name) in it changes - it changes some fields in related entity (lets say it called Company). The Company has also embedded entity Address , that is not changing. In the end of listener - as suggested in [documentation](https://www.doctrine-project.org/projects/doctrine-orm/en/2.19/reference/events.html) - i'm calling recomputeSingleEntityChangeSet for Company to get changes registered. But after doing that - i have address appearing in the changeSet, like it changed from null to actual object. If i call computeChangeSet instead of recomputeSingleEntityChangeSet - changeSet looks as expected doctrine/orm version 2.19 and 2.20 (tried on both)

admin commented

2026-01-22 15:23:10 +01:00

@uerka commented on GitHub (Dec 3, 2024):

futher debugging shows me that possibly issue is in following piece:

          if (! (isset($originalData[$propName]) || array_key_exists($propName, $originalData))) {
                              continue;
          }

that exists for computeChangeSet, but missing in recomputeSingleEntityChangeSet. It seems that it also like that for newer doctrine versions.

im not sure how should we handle that - is it a bug or it was done on purpose? recomputeSingleEntityChangeSet marked as internal (although documentation mentions it as a way to go) - should we handle it in some other way?

@uerka commented on GitHub (Dec 3, 2024): futher debugging shows me that possibly issue is in [following piece](https://github.com/doctrine/orm/blob/8ed6c2234aba019f9737a6bcc9516438e62da27c/src/UnitOfWork.php#L769): ```php if (! (isset($originalData[$propName]) || array_key_exists($propName, $originalData))) { continue; } ``` that exists for computeChangeSet, but missing in recomputeSingleEntityChangeSet. It seems that it also like that for newer doctrine versions. im not sure how should we handle that - is it a bug or it was done on purpose? recomputeSingleEntityChangeSet marked as internal (although documentation mentions it as a way to go) - should we handle it in some other way?

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