[Mondrian] Scoped solve order / Aggregate

Matt Campbell mkambol at gmail.com
Tue Jun 9 11:31:47 EDT 2009


There already are a good set of tests I had forgotten
about-- SolveOrderScopeIsolationTest.  It just never got added to Main.

On Tue, Jun 9, 2009 at 10:55 AM, Matt Campbell <mkambol at gmail.com> wrote:

> Julian,
> 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())) {
>                     continue;
>                 }
>
> Version 88--
>             case CUBE_SCOPE:
>                 if (maxSolveMember.containsAggregateFunction()) {
>                     continue;
>                 }
>
> 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/d097891f/attachment.html 


More information about the Mondrian mailing list