On 5 avr. 2013, at 05:23, Matteius <matte...@gmail.com> wrote: > Django's get_or_create does a Get, failing that a create, failing that a > rollback and another get. For some reason in MySQL, and to me conceptually > the code roll back to prior to the commit when the other thread wins in the > create block and saves the object, it still doesn't exist when the other > thread tries to get it a final time, because I believe it rolled back to the > earlier pre-save savepoint.
That's because MySQL runs at the repeatable read isolation level by default. After you fail reading a row, you will never be able to read it within the same transaction, even if it's created by another transaction in the mean time. https://code.djangoproject.com/ticket/13906 > The question for me is: Why wouldn't we want this to be this way?: > transaction.commit() # To refresh the DB view for thread > safety I'm not sure what the consequences would be in Django 1.5. However, I can say it isn't appropriate in the new transaction management model introduced in Django 1.6, because calling "commit" within an atomic block raises an error. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
