Okay - anyone else want to throw their thoughts at this? Also - messing with the isolation levels on MySQL is really not a great idea.. it can cause all sorts of unexpected behavior.
Cal On Mon, Jul 16, 2012 at 7:28 PM, Anssi Kääriäinen <[email protected]>wrote: > On 16 heinä, 14:00, "Cal Leeming [Simplicity Media Ltd]" > <[email protected]> wrote: > > Hi guys, > > > > Okay so, this has been marked as wontfix in its current approach. > > > > The problem exists purely because of the way MySQL transactions and > indexes > > work - if you create a row that matches a unique index, it won't show up > as > > a row until you commit (which is correct), but if you try and insert > > another row that matches this same unique index it will say the key > already > > exists (this is to prevent unique constraint race conditions within > > transactions). > > > > This really isn't a bug in the code, but more that developers need to > > understand how the database works, and take the appropriate actions (in > > this case, it's that you need to commit() the transaction to guarantee > safe > > usage of get_or_create()). > > > > As aaugustin brought up, we can't automatically commit as this would > break > > transaction control, and there is little point in adding a 'commit=True' > > argument onto get_or_create() because you could just do this yourself. > > > > Therefore, I'm proposing a documentation update that highlights and > > explains this in a clear and simple way - rather than any sort of code > > change. Would this be an appropriate way forward? > > I have tried different ways of solving this issue. To me it seems that > unless one does a commit in get_or_create or changes the default > isolation level used by MySQL then there is no cure for this issue. > And this issue seems to pop out regularly. I don't the above mentioned > approaches as good solutions. > > I would like to see the possibility to use different isolation levels > if the user chooses so. This would be a good solution in my opinion: > use READ COMMITTED isolation level if you are having problems with > get_or_create. Allowing use of different isolation levels has other > advantages, too. The use of custom isolation level should come with a > big warning of "you should know what you are doing, or prepare for > trouble". > > So, lets document the current behavior for now, and check if we can do > something to the isolation level issue later on. > > - Anssi > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
