#28806: Mechanism of fetching related objects violates READ COMMITTED 
assumption of
Django ORM
-------------------------------------+-------------------------------------
     Reporter:  Aaron Tan            |                    Owner:  nobody
         Type:  Bug                  |                   Status:  new
    Component:  Database layer       |                  Version:  master
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:
     Keywords:  database, read-      |             Triage Stage:
  committed, concurrency control     |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by Aaron Tan):

 Replying to [comment:1 Tomer Chachamu]:
 > The comment is definitely inaccurate, but I don't think the attribute
 returning {{{None}}} is the right answer. Sure, the FK is set to NULL on
 conflict, but maybe transaction B also updated
 {{{Bar.objects.get(pk=<bar's pk>).pk}}} to a new value? In this case, A
 will see the new value after a {{{bar.refresh_from_db()}}}, that is not
 {{{None}}}.
 >
 > The docs could probably be improved, to mention that you can use
 {{{select_related}}} to prevent this {{{DoesNotExist}}} from being thrown.
 (Although, it doesn't remove the fact that you will insert on save, when
 you probably meant to update).

 I see, although manually modifying primary key seems like a kinda
 infrequent operation, but that makes sense. In this case, can we at least
 capture {{{ObjectDoesNotExist}}} there and make a partial
 `refresh_from_database` by only refreshing and instantiating the related
 field in question? Since selector works on a pretty low level of Django's
 call stack, it might be possible to do that? After all, this means "any
 fetching related object for the first time is theoretically vulnerable to
 such concurrency issue", wrapping all of them around {{{try...except...}}}
 is cumbersome and error-prone in large and convoluted codebases.

 Also, using {{{select_related}}} to supress {{{DoesNotExist}}} was our
 first solution, but somehow it does not work. Maybe it is worth
 investigating/experimenting.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/28806#comment:2>
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 updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.41c24f8212ac36cf11dbe757aad6d3e3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to