You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the class IndexAggregateFunction (and derivates) use a KeyExpression called operand to represent both grouping expressions, and grouped expressions (the aggregate function's argument(s)). We also allow for certain attributes of this class, specifically index to be nulled out or not. In general it appears as if there are two different versions of objects created from this class:
function objects that do not have an index (they are unbound)
function objects that do have an index set (they are bound to that said index)
Interestingly, there is no point fixing the order of the grouping expressions when such a function is not yet bound to an index as the index dictates the order of these expressions.
This issue should target the separation of these two use cases into two actual classes, one for the bound and one for the unbound case. In the unbound case we want to represent the grouping keys in set rather than positionally fixed.
The text was updated successfully, but these errors were encountered:
normen662
changed the title
represent an aggregation function as using a set of aggregation keys rather than a list
represent an aggregation function as using a set of aggregation keys rather than a KeyExpression
Mar 11, 2021
normen662
changed the title
represent an aggregation function as using a set of aggregation keys rather than a KeyExpression
represent an aggregation function using a set of aggregation keys rather than a KeyExpression
Mar 11, 2021
Currently the class
IndexAggregateFunction
(and derivates) use aKeyExpression
calledoperand
to represent both grouping expressions, and grouped expressions (the aggregate function's argument(s)). We also allow for certain attributes of this class, specificallyindex
to be nulled out or not. In general it appears as if there are two different versions of objects created from this class:Interestingly, there is no point fixing the order of the grouping expressions when such a function is not yet bound to an index as the index dictates the order of these expressions.
This issue should target the separation of these two use cases into two actual classes, one for the bound and one for the unbound case. In the unbound case we want to represent the grouping keys in set rather than positionally fixed.
The text was updated successfully, but these errors were encountered: