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? Cal ---------- Forwarded message ---------- From: Django <[email protected]> Date: Thu, Jul 12, 2012 at 10:25 PM Subject: Re: [Django] #18557: get_or_create() causes a race condition with MySQL To: Cc: [email protected] #18557: get_or_create() causes a race condition with MySQL -------------------------------------+------------------------------------- Reporter: foxwhisper | Owner: nobody Type: Uncategorized | Status: closed Component: Database layer | Version: 1.4 (models, ORM) | Resolution: wontfix Severity: Normal | Triage Stage: Keywords: | Unreviewed Has patch: 0 | Needs documentation: 0 Needs tests: 0 | Patch needs improvement: 0 Easy pickings: 0 | UI/UX: 0 -------------------------------------+------------------------------------- Changes (by aaugustin): * status: reopened => closed * resolution: => wontfix Comment: Replying to [ticket:18557 foxwhisper]: > Is there any chance this patch would make it into the core? [[BR]] To be honest, as is, there is no chance for this code to make it into Django: - it isn't a patch, just a chunk of code, - it's specific to MySQL but it appears that it should go into django.db.models, - there's no explanation of why you're using this technique and why it works, and it isn't strikingly obvious either, - it messes transaction control, - no tests, no docs, - the code itself very far from Django's coding standards (`print`, `raise Exception`, etc.) Regarding transaction control, I see you've put the responsibility on the developer. It's hand-vawing, and I don't think we can put the issue aside like this. Transaction control is one of the more complicated parts of Django and I don't expect more than 0.1% of the framework's users to understand it. (I don't understand it completely myself.) I acknowledge that the problem exists, but this specific piece of code doesn't look like an appropriate solution, at least not in its current state. The way to move forward on a ticket that received a wontfix by a core developer is to bring up the issue on django-developers. Thanks! -- Ticket URL: <https://code.djangoproject.com/ticket/18557#comment:4> Django <https://code.djangoproject.com/> The Web framework for perfectionists with deadlines. -- 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.
