#30124: QuerySet.only() on reverse many-to-one relationship causes extra 
database
queries
-------------------------------------+-------------------------------------
     Reporter:  Beda Kosata          |                    Owner:  Dan Davis
         Type:  Bug                  |                   Status:  assigned
    Component:  Database layer       |                  Version:  2.1
  (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
-------------------------------------+-------------------------------------

Comment (by Dan Davis):

 There seem to be two general approaches here:

 === only is intended for fields of the base table

 So, if the alias_map has cardinality > 1, then detect fields that are not
 from the base table and raise a warning.  Since only is an optimization,
 the warning alerts the user to the problem, but his/her webapp simply
 continues to work, albeit slower.   In a reverse relationship, the
 parent's key is a field of the base table - add it automatically.   This
 doesn't necessarily mean that the pk of the parent table will be added.
 If the ForeignKey is on something other than the parent pk, then the
 parent pk is not what is added to the response.  This would fix this
 issue, #30124, and in the case of #23051, a warning would be raised and
 the call to only would not modify the query.   Since only is an
 optimization, this may be acceptable.

 === only is not intended for joins

 So, if the table_map has cardinality > 1, then raise some warning so that
 we can gain feedback from users, and if reasonable, deprecate at a later
 time.   The code in #30124 would have to be done with defer() or values(),
 which could in a real-world case be a lot of fields and a great loss of
 utility.   #23051 would similarly cause a warning, but here the warning
 might be better received ;).

 Are there implications of this on other query types, such as
 union/difference, etc.?

-- 
Ticket URL: <https://code.djangoproject.com/ticket/30124#comment:4>
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/064.78390cfb83f56a92d8a75462fa22894e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to