UnitOfWork incorrect compute change set when entity have property with \DateTime type #6166

New Issue

admin · 2026-01-22T15:28:04+01:00

admin commented

2026-01-22 15:28:04 +01:00

Originally created by @vyacheslav-startsev on GitHub (Jan 26, 2019).

Originally assigned to: @Ocramius on GitHub.

Bug Report

Q	A
BC Break	no
Version	2.6.3

Summary

Method computeChangeSet in UnitOfWork wrong set entity as scheduled for update when entity is not updated really.

Current behavior

This bug appears when some property in the entity is object (for example, instance of \DateTime).
It happens because at the https://github.com/doctrine/orm/blob/2.6/lib/Doctrine/ORM/UnitOfWork.php#L696 used identity comparison operator (===) but in PHP object variables are identical if and only if they refer to the same instance of the same class. (see http://php.net/manual/en/language.oop5.object-comparison.php)

How to reproduce

https://github.com/doctrine/orm/pull/7584

Expected behavior

UnitOfWork will not mark an entity as updated if old and new values in datetime properties are equal.

Originally created by @vyacheslav-startsev on GitHub (Jan 26, 2019). Originally assigned to: @Ocramius on GitHub. ### Bug Report | Q | A |------------ | ------ | BC Break | no | Version | 2.6.3 #### Summary Method `computeChangeSet` in `UnitOfWork` wrong set entity as scheduled for update when entity is not updated really. #### Current behavior This bug appears when some property in the entity is object (for example, instance of `\DateTime`). It happens because at the https://github.com/doctrine/orm/blob/2.6/lib/Doctrine/ORM/UnitOfWork.php#L696 used identity comparison operator (===) but in PHP object variables are identical if and only if they refer to the same instance of the same class. (see http://php.net/manual/en/language.oop5.object-comparison.php) #### How to reproduce https://github.com/doctrine/orm/pull/7584 #### Expected behavior UnitOfWork will not mark an entity as updated if old and new values in datetime properties are equal.

admin added the Invalid Question labels 2026-01-22 15:28:04 +01:00

admin closed this issue

2026-01-22 15:28:04 +01:00

admin commented

2026-01-22 15:28:04 +01:00

@SenseException commented on GitHub (Jan 28, 2019):

Thank you for contributing a test to the issue. Every type would need some kind of comparator for the check of a changed value. I don't know about the impact to the UnitOfWork when a lot of entities have to be checked for changes.

See comment https://github.com/doctrine/orm/pull/7586#discussion_r251602186 about simple object comparisons (#7586)

@SenseException commented on GitHub (Jan 28, 2019): Thank you for contributing a test to the issue. Every type would need some kind of comparator for the check of a changed value. I don't know about the impact to the UnitOfWork when a lot of entities have to be checked for changes. See comment https://github.com/doctrine/orm/pull/7586#discussion_r251602186 about simple object comparisons (#7586)

admin commented

2026-01-22 15:28:05 +01:00

@Ocramius commented on GitHub (Jan 28, 2019):

This is the correct/expected behavior for the ORM: closing as invalid.

Also see https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/cookbook/working-with-datetime.html
Also see https://stackoverflow.com/questions/15486402/doctrine2-orm-does-not-save-changes-to-a-datetime-field

@Ocramius commented on GitHub (Jan 28, 2019): This is the correct/expected behavior for the ORM: closing as `invalid`. Also see https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/cookbook/working-with-datetime.html Also see https://stackoverflow.com/questions/15486402/doctrine2-orm-does-not-save-changes-to-a-datetime-field

admin commented

2026-01-22 15:28:06 +01:00

@filiplikavcan commented on GitHub (Jan 14, 2021):

Hm, why is this a correct/expected behaviour? ORM knows how to serialise DateTime property so what is the reason to not use that ability to detect change by using an actual serialised value?

@filiplikavcan commented on GitHub (Jan 14, 2021): Hm, why is this a correct/expected behaviour? ORM knows how to serialise DateTime property so what is the reason to not use that ability to detect change by using an actual serialised value?

admin commented

2026-01-22 15:28:06 +01:00

@bogdan-dubyk commented on GitHub (Dec 18, 2024):

In my case, I have

$updatedAt = $entity->getUpdatedAt();
$updatedAtSrting = $updatedAt->formtat('format');
//some functionality here
$entity->setUpdatedAt(DateTime::createFromFormat('format', $value));

in 95%, the date will remain the same, but as it's a new and different object, UOW will consider it a change and will lead to an unnecessary database query

@bogdan-dubyk commented on GitHub (Dec 18, 2024): In my case, I have ``` $updatedAt = $entity->getUpdatedAt(); $updatedAtSrting = $updatedAt->formtat('format'); //some functionality here $entity->setUpdatedAt(DateTime::createFromFormat('format', $value)); ``` in 95%, the date will remain the same, but as it's a new and different object, UOW will consider it a change and will lead to an unnecessary database query

admin referenced this issue

2026-01-22 16:05:42 +01:00

[PR #6166] Normalise codebase with PHP 5.6 features #9877

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