#27683: Change default transaction isolation level to READ COMMITTED on MySQL
-------------------------------------+-------------------------------------
Reporter: Shai | Owner: nobody
Berger |
Type: New | Status: new
feature |
Component: Database | Version: master
layer (models, ORM) |
Severity: Release | Keywords:
blocker |
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 1 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
There have been plenty of bug reports and discussions about the problems
caused for users by MySQL's implementation of the REPEATABLE READ
transaction isolation level, and the fact that it is the default. Django
is mostly written for READ COMMITTED; of all supported backends, MySQL is
the only one to use a different level by default. Things will probably run
more in line with users expectations under READ COMMITTED, and reusable
apps' behavior will be more similar across database backends.
Some history: This has been raised already in the [#13906 1.2 era], and
possibly even before that; the question was raised in different forms
[#14026 again] and [#21670 again] until one more [#26347 instance] caused
it to be brought up on the mailing list. To be sure, it wasn't the first
time the issue was brought to the list either, but
[https://groups.google.com/forum/#!msg/django-
developers/6pWbpV1_6Us/a3CNmojACwAJ this discussion] seemed to conclude
with a rough consensus that the default transaction isolation level for
MySQL should change. As far as I'm aware, the issue has not been discussed
since then.
There are two kinds of backwards-compatibility problems I already see with
this change:
1) The obvious one -- Apps that are written to be correct under MySQL's
REPEATABLE READ isolation level may become subtly incorrect by default.
This is a very real problem, and hard to tackle because writing tests to
capture the problems is very hard -- one needs to make and use at least
two separate connections to the same database, and the Django ORM (and
testing framework) does not make that easy. The counter-argument to that
is that we likely have plenty of apps -- reusable or otherwise -- that are
currently subtly wrong because MySQL's REPEATABLE READ semantics is
surprising and unintuitive.
2) The less obvious one -- the way to set transaction isolation levels is
with SQL executed when the connection is opened, and we need to make sure
we don't interrupt with the user's own `init_command` if there is one.
Some very basic intro to transaction isolation levels in general and
MySQL's REPEATABLE READ in particular is in my DC.EU.2016 lightning talk
about this:
https://opbeat.com/community/posts/lightning-talks-day-1/ (starting around
4:00).
--
Ticket URL: <https://code.djangoproject.com/ticket/27683>
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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/048.453a60d31c844fa478ec5758bfd5cea0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
