subject:"\[Django\] #27403\: prefetch_related doesn't guarantee transactional consistency"

Re: [Django] #27403: prefetch_related doesn't guarantee transactional consistency

2017-04-06 Thread Django

* cc: Shai Berger (added)

Comment:

Rivo, I think you're wrong, but not in the direction you suspected: In
fact, REPEATABLE READ would still not fix this, and as far as I
understand, on any database that isn't PG, even SERIALIZABLE won't --
unless we first select (with no need to fetch) the join of the tables. But
that would undo much of the performance benefits of `prefetch_related`...

Some databse engines -- notably SQL Server -- can return several result
sets (=querysets) from a single command (typically a procedure call).
Something like that could, at least in principle, help us here.

--
Ticket URL:
Django
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.489b0a00fa32f61e1c5169545e49d017%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27403: prefetch_related doesn't guarantee transactional consistency

2017-04-06 Thread Django

Comment (by Rivo Laks):

Correct me if I'm wrong, but I think just wrapping the
`prefetch_related()` in a transaction wouldn't fix this.

By default, at least in Postgres, queries made within a transaction can
still see data from other _committed_ transactions, so the same problem
would occur.

In Postgres, you could select a higher isolation level, I think Repeatable
Read would prevent the case you've described. But this has other
consequences and should be done on per-app basis. See
https://www.postgresql.org/docs/current/static/transaction-iso.html for
more info.

If I'm right, maybe docs should note that there might be edge cases
regards transactional consistency?

--
Ticket URL:
Django
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.4d359a0451aeef960a53bb58cda9d014%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27403: prefetch_related doesn't guarantee transactional consistency

2016-11-01 Thread Django

#27403: prefetch_related doesn't guarantee transactional consistency
-+-
 Reporter:  Aymeric Augustin |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


--
Ticket URL: 
Django 
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.eaa2c99e06004b74fd34799f24319370%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27403: prefetch_related doesn't guarantee transactional consistency

2016-10-29 Thread Django

#27403: prefetch_related doesn't guarantee transactional consistency
-+-
   Reporter:  Aymeric|  Owner:  nobody
  Augustin   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Let's assume a `Parent` model and a `Child` model with a FK to `Parent`.

 Database initially looks like this:
 {{{
 parent1 -- child1
 }}}

 User runs `Parent.objects.all().prefetch_related('child_set')`.

 Django fetches `parent1`.

 Another transaction commits, resulting in this structure:
 {{{
 parent1 +- child1
 `- child2
 parent2
 }}}

 Django fetches all children pointing to `parent1`, which returns `child1`
 and `child2`.

 The result of the query is:
 {{{
 parent1 +- child1
 `- child2
 }}}

 But at no point in the history did the database look like this.

 This bug report is based on code inspection.

 I verified that `prefetch_related` doesn't start a transaction.

 However I didn't write code exhibiting the race condition because that's a
 bit complicated.

--
Ticket URL: 
Django 
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/052.da26f2bbf233a95ac24e6749515421c6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27403: prefetch_related doesn't guarantee transactional consistency

Re: [Django] #27403: prefetch_related doesn't guarantee transactional consistency

Re: [Django] #27403: prefetch_related doesn't guarantee transactional consistency

[Django] #27403: prefetch_related doesn't guarantee transactional consistency

4 matches

Site Navigation

Mail list logo

Footer information