In ticket #27683 [0], Shai proposed to change Django to default to using the READ COMMITTED isolation level. Some background on the reasons are on the ticket and in another thread [1] (possible data loss is involved).
The initial approach [2] that Shai put forward is adding a deprecation warning and a system check: - The deprecation warning says, "Django's default transaction isolation level on MySQL is going to change from REPEATABLE READ (MySQL's default) to READ COMMITTED. Specify an explicit level by setting 'isolation_level' in 'OPTIONS' in the connection settings." - The system check warning (visible when running migrate) says, "Transaction isolation level for database connection 'default' is 'REPEATABLE-READ'. Django and many of its apps are written to work correctly under the READ COMMITTED transaction isolation level. MySQL's default level, REPEATABLE READ, may imply some surprising behaviors under concurrent loads, leading to possible data loss. It is recommended that you change the transaction isolation level." If an isolation level isn't specified in DATABASES['OPTIONS'], Django would start setting a READ COMMITTED isolation level in Django 2.1. Both the system check (since it wouldn't trigger anymore) and the deprecation warning would be removed at that time. The reason for having both a check and a deprecation warning seems to be that deprecation warnings are silent by default. An alternate idea is to skip the deprecation cycle and make Django start setting the default isolation in Django 1.11. I'm not sure if giving projects two release cycles to choose their isolation level adds value. In the "no thinking involved" case, it's not difficult to specify what's being used now, REPEATABLE READ. If Django changed the isolation level in 1.11, a "compatibility" system check could raise a warning if 'isolation_level' isn't specified in the database settings. This leaves projects in the same place as the first approach, where all MySQL projects have to specify an isolation level to silence a warning. That check would be removed in Django 2.0, which avoids another 8 months of new MySQL projects (started with Django 2.0) having a check and/or deprecation warning out of the box that the first approach requires. (Ideally, the compatibility system check could differentiate between existing projects and new projects in Django 1.11, but past heuristics to do this involving examining settings and comparing them to the startproject defaults haven't been accurate.) Shai said, "The deprecation period may be required because although the warnings and settings are at the project level, there may be code changes required at the app level, and it may be better to keep the new projects aware of the issue while 3rd parties adapt." I don't know enough to say whether or not that's the case. Anyway, I think a project could evaluate their apps and make a decision to stay with REPEATABLE READ or to switch to READ COMMITTED. How do MySQL users feel about the two approaches? [0] https://code.djangoproject.com/ticket/27683 [1] https://groups.google.com/d/topic/django-developers/6pWbpV1_6Us/discussion [2] https://github.com/django/django/pull/7826 -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1c8af1c8-23dd-4c79-85ce-9486290ae73f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
