[Mondrian] Scoped solve order / Aggregate

Matt Campbell mkambol at gmail.com
Tue Jun 9 10:55:45 EDT 2009

It looks like there was just one issue with your refactor-- the logic for
determining max solve order when the aggregate function is involved got
flipped in two places.  In RolapEvaluator.getScopedMaxSolveOrder() you
modified the check for the aggregate function in QUERY_SCOPE and CUBE_SCOPE
to look at the member with the current max solve order, rather than the
current member:
Version 87--
            case CUBE_SCOPE:
                if (foundAggregateFunction(member.getExpression())) {

Version 88--
            case CUBE_SCOPE:
                if (maxSolveMember.containsAggregateFunction()) {

This change makes members containing the Aggregate function have the highest
solve order, which is the opposite of what we want. SSAS 2005 and above
automatically sets any member with Aggregate to have the lower solve order
than any intersecting member. (see the first note in
http://msdn.microsoft.com/en-us/library/ms145539.aspx).  Keeping the solve
order of aggregate lower ensures that aggregation will happen over
components of a calculation, rather than attempting to aggregate the
calculation itself.

The fix should be as simple as swapping maxSolveMember with member in the
conditional above.  Any objections to me making the change?  I'll also add
some tests for scoped solve order--it looks like there are none right now.

On Thu, Jun 4, 2009 at 9:11 PM, Julian Hyde <jhyde at pentaho.com> wrote:

>  Look at my change 12728, which changed the part of the query lifecycle
> when solve order mode is read from the properties file. It's possible that
> this is responsible. This change improved performance significantly, and is
> correct as far as I know, so I would like to hear a justification before you
> reverse it.
>  ------------------------------
> *From:* mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org]
> *On Behalf Of *Matt Campbell
> *Sent:* Thursday, June 04, 2009 6:00 AM
> *To:* Mondrian developer mailing list
> *Subject:* [Mondrian] Scoped solve order / Aggregate
> I noticed today that Scoped solve order is broken with Aggregate().
>  If mondrian.rolap.SolveOrderMode=scoped, then the following query will
> fail:
>  with member [marital status].agg as 'Aggregate([marital status].[marital
> status].members)'
> select   crossjoin( {Gender.Gender.M}, {[marital status].[marital
> status].members, [marital status].agg} )  on 0, { measures.[profit growth] }
> on 1 from sales;
> This throws the exception:
>  mondrian.olap.fun.MondrianEvaluationException: Could not find an
> aggregator in the current evaluation context
> I'll look into it some more here, but I'm curious if anyone knows of recent
> checkins that might be responsible.
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20090609/34ebb61d/attachment.html 

More information about the Mondrian mailing list