[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