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

Comment (by nate_b):

 The patches posted here are insufficient to effectively solve this
 problem.

 I have come up with a better solution: refactoring of Aggregate into
 ExpressionNode.

 I have uploaded my branch; it can be found here:

 https://github.com/NateBragg/django/tree/14030

 Some particular points of note:
 * I tried to preserve as much interface as possible; I didn't know how
 much was considered to be more public, so generally I tried to add rather
 than subtract.  However, I did remove a couple things - if you see
 something missing that shouldn't be, let me know.
 * Currently, I'm getting the entire test suite passed on sqlite, postgres,
 mysql, oracle, and postgis.  I was unable to test on oracle spatial - any
 help with that would be appreciated.
 * When fields are combined, they are coerced to a common type;
 IntegerFields are coerced to FloatFields, which are coerced into
 DecimalFields as needed.  Any other kinds of combinations must be of the
 same types.  Also, when coerced to a DecimalField, the precision is
 limited by the original DecimalField.  If this is not correct, or other
 coercions should be added, I'd like to correct that.
 * When joins are required, they tend to be LEFT OUTER; I'd like some
 feedback on this, as I'm not 100% sure its always the best behavior.
 * As the aggregates are a little more complicated, on trivial cases there
 is a minor reduction in performance; using djangobench, I measured
 somewhere between a 3% and 8% increase in runtime.
 * I don't have enough tests - mostly for a lack of creativity.  What kind
 of composed aggregates and expressions would you like to see?  I'll add
 tests for them.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/14030#comment:17>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Reply via email to