#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 |
-------------------------------------+-------------------------------------
Changes (by jsdalton):
* cc: jim.dalton@… (added)
* needs_better_patch: 0 => 1
* needs_docs: 0 => 1
Comment:
It seems like the consensus is pretty strong that the problem is being
caused by REPEATABLE READ and that the solution to the problem is
switching the isolation mode to READ COMMITTED. It also sounds like,
judging from TomaszZielinski's comment above, READ COMMITTED can cause
erratic behavior sometimes.
MySQL users are basically going to have to pick their poison: a) go with
REPEATABLE READ, which is more proven (and probably more dependable) but
which will cause ORM behavior that is inconsistent with other backends, or
b) go with READ COMMITTED, which will provide for consistent ORM behavior
but could *possibly* result in other issues.
I don't see any other alternatives so I agree that the current patch has
the right idea. That said, the current patch is more of a suggested
workaround than a solution. I'd like to argue for stronger support of the
set isolation level feature, akin to what's available for the Postgresql
backend. I also think whatever we do needs documentation.
So I'm thinking about:
* An explicit key `isolation_level` in the db `OPTIONS` dict for MySQL
(akin to the `autocommit` key for Postgresql). Possible values would be
one of `['READ-UNCOMMITTED', 'READ-COMMITTED', 'REPEATABLE-READ',
'SERIALIZABLE']`.
* A `set_isolation_level` method on the DatabaseWrapper which implements
the SET TRANSACTION statement. This should be triggered in
`DatabaseWrapper.__init__`. Should probably set an `isolation_level`
attribute so the isolation level status can be checked.
* Tests for the feature.
* Documentation for the feature in database notes, with a brief
explanation of the tradeoffs.
This is more or less what the OP was describing as his suggested fix.
I'd be happy to work on a patch for along these lines, but just wanted to
see if anyone else thinks the above makes sense. Let me know...
--
Ticket URL: <https://code.djangoproject.com/ticket/13906#comment:18>
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.
