#27683: Change default transaction isolation level to READ COMMITTED on MySQL
-------------------------------------+-------------------------------------
Reporter: Shai Berger | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) |
Severity: Release blocker | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Old description:
> 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).
New description:
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 [ticket:13906 1.2 era],
and possibly even before that; the question was raised in different forms
[ticket:14026 again] and [ticket:21670 again] until one more [ticket: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).
--
Comment (by Karen Tracey):
We really should do this! (Unfortunately I have no energy/time to devote.
But I did fix up the ticket links in the description.)
--
Ticket URL: <https://code.djangoproject.com/ticket/27683#comment:3>
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/063.7ed9f13a72f6b18932dd08f23d4d8638%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
