Changes between Initial Version and Version 1 of Ticket #14030, comment 17


Ignore:
Timestamp:
Mar 23, 2012, 5:03:54 AM (12 years ago)
Author:
Nate Bragg

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #14030, comment 17

    initial v1  
    11The patches posted here are insufficient to effectively solve this problem.
    22
    3 I have come up with a better solution: refactoring of Aggregate into ExpressionNode.
     3I have come up with a better solution: refactoring of {{{Aggregate}}} into {{{ExpressionNode}}}.
    44
    55I have uploaded my branch; it can be found here:
    … …  
    1010* 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.
    1111* 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.
    12 * 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.
    13 * 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.
     12* When fields are combined, they are coerced to a common type; {{{IntegerField}}}s are coerced to {{{FloatField}}}s, which are coerced into {{{DecimalField}}}s 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.
     13* 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.
    1414* 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.
    1515* 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.
Back to Top