Unfortunately, no. I understand transaction isolation levels. By the way, I'm using MySQL InnoDB which has similar isolation level settings to PostgreSQL. Regardless of the isolation level, the one of the two concurrent creates will fails. They are atomic and add data that will voliate a UNIQUE constraint. My proposal is to fold in a common handler into get_or_create() so that it will always return the object that you tried to get/create in keeping with the DRY priciple. Otherwise, if it lets the exception escape, then everywhere I call get_or_create() will have to implement a very non-DRY piece of identical code to handle the situation.
Travis Leo Soto M. wrote: > On Dec 4, 2007 3:08 PM, Travis Terry <[EMAIL PROTECTED]> wrote: > >> I've run into a problem with get_or_create() with respect to concurrent >> access of the DB, and I have looked at the list archives for advice. I >> found some discussions a while back regarding other's problems but no >> acceptable solution was ever implemented. >> > > Isn't the serializable transaction isolation level[1] what you are looking > for? > > [1] > http://www.postgresql.org/docs/7.4/interactive/transaction-iso.html#XACT-SERIALIZABLE > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
