While there are some different opinions expressed here (mine included), the rough consensus seems to be to apply the for_update() patch to 1.8.x (it is neither needed nor applicable to 1.9.x) and change the transaction isolation level for 1.10 and going forward.
To the best of my knowledge, nobody is working on patches yet, I have had no time for it myself in the last few days. On Thursday 24 March 2016 21:45:02 Ben Cail wrote: > What's the current status on this? Is the .for_update() change mentioned > in the bug report the best way to go? Is anyone working on a PR? > > On 03/18/2016 05:15 PM, Karen Tracey wrote: > > This is the 2nd major issue I can recall caused by MySQL default of > > REPEATABLE READ transaction isolation level. I think Django should > > simply switch itself to a default of using READ COMMITTED, consistent > > with (all?) other supported database backends, and document how, if a > > user really really wants to use REPEATABLE READ, they can do so (I > > assume Django could allow that?), and what known problems when using > > basic Django functions they may run into if they do so. > > > > I fear our existing approach of documenting how certain functions > > don't work by default on MySQL (e.g. get_or_create) is not really > > helping the majority of our users. I believe switching instead to > > making Django code itself work by default on MySQL would be a better > > long-term solution for those who use MySQL with Django, and avoid > > future cases like this one that has been discovered (years after we > > knew get_or_create was broken by default transaction isolation level > > on MySQL). > > > > On Mon, Mar 14, 2016 at 11:15 AM, Tim Graham <timogra...@gmail.com > > > > <mailto:timogra...@gmail.com>> wrote: > > Could some MySQL users take a look at ticket #26347 [0] and > > recommend how to proceed? I think it's probably not a new issue > > but I'm a bit surprised it hasn't come up before if so. > > > > [0] https://code.djangoproject.com/ticket/26347
