-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Proposed fix for #8499 #8508
Proposed fix for #8499 #8508
Conversation
Please improve your commit message according to the contributing guide. |
Done. |
I meant the commit message, so you can squash your current commits together, and reuse your PR message as a commit message. BTW, when you create a PR with just one commit, Github will reuse its message as a PR message. |
I hope it's ok now. |
I will do it for you. |
|
🤔 is this line wrong:
\DateTimeInterface although the docs do mention using a datetime field as a revision: https://www.doctrine-project.org/projects/doctrine-orm/en/latest/reference/transactions-and-concurrency.html#locking-support
This line might be wrong too: orm/lib/Doctrine/ORM/UnitOfWork.php Line 2461 in e40ac3e
|
…ace objects directly. When using optimistic lock with DateTimeInterface based version field a bug appears due to the use of the === operator for comparing the lock version and the entity version. This comparison always resolves to false because the === operator when comparing objects is only true when both sides are the exact same instance of the object. To fix the issue I have decided to compare timestamps instead the DateTimeInterface based objects directly, calling getTimestamp() method and doing a strict comparison. Modified OptimisticLockException to use DateTimeInterface instead of DateTime class. Added test suite to cover case. Fixes #8499
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.
Looks great 👍
Changed lock function to compare timestamps instead of DateTimeInterface objects directly.
When using optimistic lock with DateTimeInterface based version field a bug appears due to the use of the === operator for comparing the lock version and the entity version. This comparison always resolves to false because the === operator when comparing objects is only true when both sides are the exact same instance of the object.
To fix the issue I have decided to compare timestamps instead the DateTimeInterface based objects directly, calling getTimestamp() method and doing a strict comparison.
Modified OptimisticLockException to use DateTimeInterface instead of DateTime class.
Added test suite to cover case.
Fixes #8499