#13105: [patch] get or create thread safety
---------------------------------------------------+------------------------
          Reporter:  toplex                        |         Owner:  toplex     
                              
            Status:  closed                        |     Milestone:             
                              
         Component:  Database layer (models, ORM)  |       Version:  1.1        
                              
        Resolution:  duplicate                     |      Keywords:  
thread;multithread;relation;get_or_create
             Stage:  Unreviewed                    |     Has_patch:  1          
                              
        Needs_docs:  0                             |   Needs_tests:  0          
                              
Needs_better_patch:  0                             |  
---------------------------------------------------+------------------------
Changes (by kmtracey):

  * status:  new => closed
  * needs_better_patch:  => 0
  * resolution:  => duplicate
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 For the regular model `get_or_create`, you won't get duplicates if you
 have specified the unique constraints on your model/database properly. The
 routine is coded to rely on the database raising an !IntegrityError for
 duplicates. I assume the same is true for adding relations, though I have
 not looked closely at that case. If there is a problem for the relation-
 adding case, when they are defined to Django as unique, then that needs to
 be spelled out in detail with example models and showing how duplicates
 can arise.

 I don't believe adding a 'fix' for the case where database unique
 constraints have not be set properly, that only works for multi-thread but
 not multi-process situations, will help here. We've already got #12759
 open for better documentation on get_or_create and the situations where it
 can be used.

 In general we would not add a fix for a multi-process/multi-thread problem
 that only addresses one of the two environments. In the case of
 `get_or_create`, we push the responsibility off to the database, which
 already has to deal with it.

 Also, for the future, patches need to be against trunk, not an existing
 release (see http://docs.djangoproject.com/en/dev/internals/contributing
 /#patch-style). The code touched in the patch has changed considerably
 since 1.1.1. First priority for bug fixes is trunk, and then fixes are
 backported to the latest release branch. Thus a patch against an old
 release doesn't help much.

-- 
Ticket URL: <http://code.djangoproject.com/ticket/13105#comment:1>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" 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-updates?hl=en.

Reply via email to