#13906: REPEATABLE READ (as used by default on MySQL) breaks atleast
QuerySet.get_or_create().
-------------------------------------+-------------------------------------
Reporter: | Owner:
sebastian_noack | Status: new
Type: | Component: Database layer
Cleanup/optimization | (models, ORM)
Milestone: 1.4 | Severity: Normal
Version: SVN | Keywords: mysql transaction
Resolution: | isolation
Triage Stage: Accepted | Has patch: 1
Needs documentation: 1 | Needs tests: 0
Patch needs improvement: 1 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Comment (by jsdalton):
@mila - I can see how SELECT FOR UPDATE would solve the particular problem
with get_or_create. Though I haven't tried implementing anything, your
demonstration is pretty convincing that it could work in this context.
One of my concerns is about the lock though. Since there is no explicit
transaction commit in get_or_create, when would SELECT FOR UPDATE release
its lock, assuming we implemented it here? The fact that it wouldn't get
released until the commit (which in many cases is at the end of a request)
could mean that it introduces some unexpected behavior into the mix. For
example, if you did a regular SELECT following all this, in the same
transaction, would it not block?
Also, this ticket is not confined to just the get_or_create issue. There's
the larger question of whether or not READ COMMITTED is a more sensible
default for MySQL to bring it in alignment with the other backends. The
only two places I'm aware of where it has been an issue is here
(get_or_create) and, interestingly enough, the select_for_update issue
that kmtracey reported, but there could be others. I still believe there
is a strong case to be made for a consistent isolation level for all
backends, particularly since Django is written with the READ COMMITTED
model in mind.
In short, I think your idea is valid (though I think there are some issues
that would still need to be worked out), but I also still think READ
COMMITTED is a more sensible default for Django.
--
Ticket URL: <https://code.djangoproject.com/ticket/13906#comment:23>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
