#14030: Use F() objects in aggregates(), annotates() and values()
-------------------------------------+-------------------------------------
     Reporter:  delfick              |                    Owner:  smeatonj
         Type:  New feature          |                   Status:  assigned
    Component:  Database layer       |                  Version:  master
  (models, ORM)                      |               Resolution:
     Severity:  Normal               |             Triage Stage:  Accepted
     Keywords:  aggregate, annotate  |      Needs documentation:  0
    Has patch:  1                    |  Patch needs improvement:  1
  Needs tests:  0                    |                    UI/UX:  0
Easy pickings:  0                    |
-------------------------------------+-------------------------------------

Comment (by smeatonj):

 The problem stems from the following block inside compiler.results_iter()

 {{{
                 if has_annotation_select:
                     loaded_fields =
 self.query.get_loaded_field_names().get(self.query.model, set()) or
 self.query.select
                     annotation_start = len(self.query.extra_select) +
 len(loaded_fields)
                     annotation_end = annotation_start +
 len(self.query.annotation_select)
 }}}

 For certain queries, loaded_fields ends up being empty. The set of fields
 appears to be fixed underneath the {{{ if resolve_columns }}} block, but
 we still have a situation where annotation_start and end are effectively
 wrong. Firstly, is the lack of a populated query.select already broken? I
 don't think it is, because we branch off the truthiness in
 resolve_columns. I think there is a bug here (expecting loaded_fields to
 always be filled) that we've been lucky hasn't bitten us elsewhere.

 What I'd like to do is completely remove these annotation_start/end
 variables, and just add the output_type of the annotation to the set of
 fields. Is there a particular reason that we aren't including the
 output_type of the aggregate in the field list? It seems that backends
 should have the opportunity to use resolve_columns to also inspect
 aggregates. The only issue with that is I believe this is truly a bug (not
 respecting loaded_fields), and should maybe be patched in a separate
 ticket. Thoughts? I'll try and put together a patch on this branch to make
 sure it's fixed, and we can extract it out if necessary.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/14030#comment:47>
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/065.67e09192fd1e96fd1df1afc914345169%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to