Sorry for my radio/email silence, I had a lot of things to do at work and wanted to think this through a bit more.
Looking again at the warning + check implementation, it is a bit messy. My goal with the check was to get a message in front of users who need it, but I suppose the release notes are good enough for this. As Aymeric says, this is very far from most Django users' concerns; it would be bothersome for most users to have to change some configuration. So I think we can get away with changing the isolation level in a release without the pre-warning message. Potentially we could still have a system check that returns a warning if using repeatable-read, because it can lead to all the bugs we've seen. Presumably it's too late to make the change in 1.11 (or is it...?) so 2.0 it is. On Friday, January 13, 2017 at 3:44:31 PM UTC, 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/49c777af-7250-4c4d-ac72-a04af01250c7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
