#25787: Add existence checks for related database sets on managers
-------------------------------------+-------------------------------------
     Reporter:  JustusAdam           |                    Owner:
                                     |  andersonresende
         Type:  New feature          |                   Status:  closed
    Component:  Database layer       |                  Version:  1.8
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:  wontfix
     Keywords:  ManyToMany,          |             Triage Stage:
  contains, in                       |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  1                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by JustusAdam):

 I understand but I think this should be explained in the documentation
 rather than using the inefficient way straight away.

 Any (normal) user, that does not dig too deep into the workings of
 QuerySets will, use {{{in}}} instead of {{{filter().exists()}}} because
 that's the python way of doing it.  I don't think it is a good idea to
 condemn them to potentially very inefficient queries for an operation that
 could be much cheaper.

 The actual behaviour of {{{__contains__}}} could be explained in the
 documentation which someone very worried about efficiency can read and
 then use {{{list()}}} to force evaluation if they need a reproducible
 query.

 {{{filter().exists()}}} poses very little overhead because it queries on
 an indexed field that I don't think we'd have to worry about the overhead.

 It is not like the current implementation doesn't have its pitfalls. Using
 {{{list()}}} on an evaluated QuerySet won't execute queries unlike on en
 unevaluated QuerySet. What I am trying to say is that operations on
 QuerySet's  ''already'' do not work the same way every time, that's simply
 their nature. As I understand the mission of django it is to abstract away
 complexity and deliver efficiency, which I believe this change would
 bring.

 Theoretically even using {{{in}}} on an evaluated query set is potentially
 very inefficient if the set is large, since it is stored in a list rather
 than a {{{set}}}.

--
Ticket URL: <https://code.djangoproject.com/ticket/25787#comment:7>
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.2688ae3e346fd8085d5b2d29a4b0898b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to