For reference there are some discussions about this in https://code.djangoproject.com/ticket/13906. The short version of the discussions is that MySQL is very interesting when it comes to transaction isolation levels and things like SELECT FOR UPDATE...
I think it would be ok to allow changing the isolation level, set the default to read committed, and document that if you use some other isolation level you are on your own. We could of course allow using different isolation levels on other databases, too. PostgreSQL's true serializable transactions for example are extremely nice for some application domains. -Anssi On Friday, January 13, 2017 at 5:44:31 PM UTC+2, Tim Graham wrote: > > In the end, I don't use MySQL but if a similar change were made for > PostgreSQL, I would find the current approach more annoying (bothering me > about changing defaults over two release cycles) than cautious. > > I'm also uncertain that duplicating a deprecation warning in a system > check is a good precedent to set. Adam, is the current implementation what > you envisioned when you made your comment and what do you see as the > advantages of that? > > Aymeric, I assume "I’d love if this fix made it into 1.10" was a typo for > 1.11. Anyway, the "Allowed transaction isolation level to be chosen on > MySQL" commit isn't controversial. I'll try to get at least that in. > > On Friday, January 13, 2017 at 10:11:26 AM UTC-5, Adam Johnson wrote: >> >> aside from some very performance-sensitive websites that already worked >>> around Django’s bugs >> >> >> Tbf it's true I already added READ-COMMITTED at work >> >> I’d love if this fix made it into 1.10 >> >> >> >> >> >> On 13 January 2017 at 15:05, Aymeric Augustin < >> aymeric.au...@polytechnique.org> wrote: >> >>> Hello, >>> >>> I think there’s been little feedback because this issue is very, very >>> far from the concerns of most Django users — aside from some very >>> performance-sensitive websites that already worked around Django’s bugs and >>> will add the configuration line needed to keep whatever the isolation level >>> they chose. >>> >>> If I was trying to merge that change, I think I’d just document the >>> backwards incompatibility and call it a day. But as everyone knows, I’m >>> taking backwards compatibility less seriously than most. >>> >>> Given the uncertainty around the consequences of this change, I don’t >>> think Shai’s approach is out of place, even though it creates an overhead >>> for every Django project using MySQL. >>> >>> Since Shai is leading the effort and considering the general lack of >>> feedback on this issue, I think it’s fair to let him make the final call >>> and keep the deprecation path if he thinks that’s safer. >>> >>> Regardless, I’d love if this fix made it into 1.10, let’s not delay it >>> because we’re worried of being too cautious :-) >>> >>> -- >>> Aymeric. >>> >>> >>> On 13 Jan 2017, at 14:52, Tim Graham <timog...@gmail.com> wrote: >>> >>> I guess three days is too little time to get a consensus on this. At >>> this point I'm thinking to defer this from 1.11. >>> >>> On Wednesday, January 11, 2017 at 9:50:27 AM UTC-5, Patryk Zawadzki >>> wrote: >>>> >>>> To add some context, REPEATABLE READ can break get_or_create among >>>> other things (not sure how many invalid tickets Django gets related to >>>> that). >>>> >>> >>> -- >>> 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-develop...@googlegroups.com. >>> To post to this group, send email to django-d...@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/42212944-d7e7-4c33-8c34-8e235a7d515a%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/django-developers/42212944-d7e7-4c33-8c34-8e235a7d515a%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >>> 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-develop...@googlegroups.com. >>> To post to this group, send email to django-d...@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/2D7B4E2A-30EF-4201-9272-C5430825E123%40polytechnique.org >>> >>> <https://groups.google.com/d/msgid/django-developers/2D7B4E2A-30EF-4201-9272-C5430825E123%40polytechnique.org?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Adam >> > -- 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/38e726b3-5726-46bd-b164-0869f97bc6c7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
