On Dec 4, 2007 4:21 PM, Travis Terry <[EMAIL PROTECTED]> wrote:
>
> 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.
No. You can use a simple external wrapper. Something along the lines of:
def get_or_create_object(klass, *args, **kwargs):
while True:
try:
return klass.get_or_create(*args, **kwargs):
except TheExceptionThatShouldNotEscape:
pass
Note that I tend to agree that Django should provide some way to deal
with this situations. My point is that if core developers don't agree
with us, we aren't forced to be non-DRY.
--
Leo Soto M.
http://blog.leosoto.com
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
