#27683: Change default transaction isolation level to READ COMMITTED on MySQL
-------------------------------------+-------------------------------------
Reporter: Shai Berger | Owner: Shai
Type: | Berger
Cleanup/optimization | Status: assigned
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Tim Graham):
As I thought about this again, I wanted to ask if a deprecation cycle
brings any value compared to this alternate strategy. It doesn't seem to
me that projects need two release cycles to choose their isolation level
-- in the easiest case they just specify what's being used now. If we
changed the default isolation level now, we could have a "compatibility"
system check raise a warning if `'isolation_level'` isn't specified in the
database settings and end up in the same place (where all MySQL projects
have to specify an isolation level to silence a warning). We could remove
that check in Django 2.0 and avoid another 8 months of new MySQL projects
having a check or deprecation warning out of the box.
--
Ticket URL: <https://code.djangoproject.com/ticket/27683#comment:11>
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/063.d7e966ed77d5920bd4ec7cbb000b8f89%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
