Joining dj.U with aggregation result leads to incorrect result

[eywalker]

I'll follow up with a detail, but currently, query like the following seems to lead to incorrect query result:

dj.U('max_val') * rel.aggr(rel2, max_val='max(vals)')

This is caused by the fact that joining with dj.U('max_val') simply appends the attribute max_val into the heading's primary keys, and when the other operand is an instance of GroupBy, then adding this attribute into the primary key attributes of GroupBy results in change in the aggregation target. To deal with this case, the GroupBy must be wrapped in subquery first.

[eywalker]

The short term work around for this issue is to wrap the result of aggregation with dj.relational_operand.Subquery as in:

dj.U('max_val') * dj.relational_operand.Subquery.create(rel.aggr(rel2, max_val='max(vals)'))

which is obviously very cumbersome and undesirable.

[dimitri-yatsenko]

Possibly related to #386

[eywalker]

Actually since it would be best to avoid sub query when possible to avoid speed issues, we might want to allow GroupBy to have aggregation target attribute that is different from the primary key in the heading.

[dimitri-yatsenko]

Yes, as long as it operates correctly from the user's perspective.