mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
DDC-681: PATCH: UnitOfWork#lock locks by column names instead of field names #840
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @doctrinebot on GitHub (Jul 10, 2010).
Originally assigned to: @beberlei on GitHub.
Jira issue originally created by user dennis.verspuij:
On line 1700 of UnitOfWork#lock column names are used instead of field names, I think the line should read:
A related question: when I load an instance by relation, e.g. $author = $book->getAuthor(), I cannot specify a lock type at that point, so I have to call $em->lock($author, LockType::PESSIMISTIC_WRITE) afterwards, which results in two database queries for the same record. Is it possible to do this at once, without setting a transaction isolation level?
@doctrinebot commented on GitHub (Jul 10, 2010):
@doctrinebot commented on GitHub (Jul 10, 2010):
Comment created by @beberlei:
Fixed the UoW issue. Thanks!
As for the second issue, there is really only one way to skip the second database call:
Use a Fetch Join DQL to get both book and author and apply the pessimistic lock to that DQL. (Locking both the book and author)
All the other way already created the Author proxy object and you won't be able to specify a locking hint on those lazy loading select statements, requiring you to do the second locking call.
@doctrinebot commented on GitHub (Jul 10, 2010):
Comment created by dennis.verspuij:
Hi Benjamin, thanks for the quick answer, I already thought you'd answer that. Only funny thing is that in my SQL log it seems the select query for the lock is called before the select query for populating the $author values! May be because it delays populating the values before its first use? In the lock could actually be done at once. Any ideas?
@doctrinebot commented on GitHub (Jul 10, 2010):
Comment created by @beberlei:
Ah ok that is a very good optimization case, let me think about how and if this is easily implementable.
I close this issue now and open up a new one
@doctrinebot commented on GitHub (Jul 10, 2010):
Issue was closed with resolution "Fixed"