-
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
Use LockMode::NONE as default lock mode #8341
Conversation
Looks like composer lock file is broken; CI can't run. |
@beberlei Could you please take a look at this PR? This should be an easy pick. |
You need to re-target your PR to a different branch, but I'm not sure if this is supposed to be a bugfix or an improvement for a newer branch. |
@SenseException This is not a bugfix, rather an improvement. Should this go into 2.9.x? What's master currently, is it 3.x? |
If master is the correct target branch, then it needs a new upmerge. It might be a current blocker. |
That's the point, I'm not sure if |
@doctrine/team-orm Is there a suggestion about the target branch for this PR? |
There hasn't been any activity on this pull request in the past 90 days, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days. |
This pull request was closed due to inactivity. |
As discussed in doctrine/dbal#4391, the
$lockMode
parameter should not be nullable anywhere; what should be used as a default isLockMode::NONE
.There was a long standing confusion in the DBAL that can be summarized to:
null
was equivalent toLockMode::NONE
;LockMode::NONE
resulted in usingWITH (NOLOCK)
, which changed the effective isolation level toREAD UNCOMMITTED
for the table; this is not the contract ofLockMode::NONE
, and was qualified as a bug.This has been fixed in doctrine/dbal#4400, and now
null
is not a valid value anymore for lock modes.This PR is the sequel to the above:
$lockMode
defaults toLockMode::NONE
everywhere,null
is not allowed anymoreLockMode::NONE
, which didn't make any senseNotes:
LockMode::NONE
was highly inconsistent anyway: theQuery
required one, butEntityManager::find()
didn't$lockMode
as well, which did document in many places that only anint
was acceptable, but did accept or even expectnull
at some point: 1, 2, 3