-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Fix false positive changes for generated columns #12018
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix false positive changes for generated columns #12018
Conversation
src/UnitOfWork.php
Outdated
|
||
foreach ($actualData as $propName => $actualValue) { | ||
if (! isset($class->associationMappings[$propName])) { | ||
if (isset($class->fieldMappings[$propName]->notInsertable)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
checking for isset
does not make sense. Both true
and false
boolean values will be considered set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds logic to me. Will change it.
I followed the style of the BasicEntityPersister but I think the same issue is over there:
orm/src/Persisters/Entity/BasicEntityPersister.php
Lines 631 to 633 in ef607f2
if ($isInsert && isset($fieldMapping->notInsertable)) { | |
continue; | |
} |
I think its working right now because the actual type seems to be null|true
instead of null|bool
looking at:
Its only set, if the flag is false.
orm/src/Mapping/Builder/FieldBuilder.php
Lines 98 to 100 in ef607f2
if (! $flag) { | |
$this->mapping['notInsertable'] = true; | |
} |
Shall I patch it in this PR or create a new one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
joy of using confusing types like null|true
instead of bool
for a boolean use case...
Based on the existing type, the code with isset
is correct then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I completely agree. I've already changed it, but would you prefer I revert it back to isset
?
Alternatively, I can create a new draft PR, since the type is defined as bool|null
and this could help prevent confusion like this in the future.
type: 'datetime_immutable', | ||
insertable: false, | ||
updatable: false, | ||
columnDefinition: 'TIMESTAMP DEFAULT CURRENT_TIMESTAMP', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this column definition is not portable across platforms, while your test is not restricted to some platforms.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed. Fixed!
UnitOfWork was incorrectly detecting changes for database-generated columns with insertable: false and updatable: false, causing entities to be scheduled for update when only generated values changed. This adds checks to skip notInsertable fields for NEW entities and notUpdatable fields for MANAGED entities during change detection, aligning UnitOfWork behavior with BasicEntityPersister. Fixes doctrine#12017
3a0fb22
to
860a64c
Compare
Can you please retarget on 3.5.x? This got closed because I deleted 3.4.x |
Yes will do that within a few days. Thanks! |
I apologize for the delay. I have retargeted it on |
UnitOfWork was incorrectly detecting changes for database-generated columns with insertable: false and updatable: false, causing entities to be scheduled for update when only generated values changed.
This adds checks to skip notInsertable fields for NEW entities and notUpdatable fields for MANAGED entities during change detection, aligning UnitOfWork behavior with BasicEntityPersister.
Fixes #12017