There already are a good set of tests I had forgotten about-- SolveOrderScopeIsolationTest. It just never got added to Main.<br><br><div class="gmail_quote">On Tue, Jun 9, 2009 at 10:55 AM, Matt Campbell <span dir="ltr"><<a href="mailto:mkambol@gmail.com">mkambol@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>Julian,</div>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:<div>
<br></div><div>Version 87--</div><div><div> case CUBE_SCOPE:</div><div> if (foundAggregateFunction(member.getExpression())) {</div><div> continue;</div><div> }</div>
<div><br></div><div>Version 88--</div></div><div><div> case CUBE_SCOPE:</div><div> if (maxSolveMember.containsAggregateFunction()) {</div><div> continue;</div><div> }</div>
<div><br></div><div>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 <a href="http://msdn.microsoft.com/en-us/library/ms145539.aspx" target="_blank">http://msdn.microsoft.com/en-us/library/ms145539.aspx</a>). 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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br><div class="gmail_quote"><div><div></div><div class="h5">On Thu, Jun 4, 2009 at 9:11 PM, Julian Hyde <span dir="ltr"><<a href="mailto:jhyde@pentaho.com" target="_blank">jhyde@pentaho.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class="h5">
<div>
<div><span><font face="Lucida Sans" color="#000080" size="2">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.</font></span></div><br>
<blockquote dir="ltr" style="padding-left:5px;margin-left:5px;border-left:#000080 2px solid;margin-right:0px">
<div lang="en-us" dir="ltr" align="left">
<hr>
<font face="Tahoma" size="2"><b>From:</b> <a href="mailto:mondrian-bounces@pentaho.org" target="_blank">mondrian-bounces@pentaho.org</a>
[mailto:<a href="mailto:mondrian-bounces@pentaho.org" target="_blank">mondrian-bounces@pentaho.org</a>] <b>On Behalf Of </b>Matt
Campbell<br><b>Sent:</b> Thursday, June 04, 2009 6:00 AM<br><b>To:</b>
Mondrian developer mailing list<br><b>Subject:</b> [Mondrian] Scoped solve
order / Aggregate<br></font><br></div><div><div></div><div>
<div></div><br>
<div>I noticed today that Scoped solve order is broken with Aggregate().
If mondrian.rolap.SolveOrderMode=scoped, then the following query
will fail:</div>
<div><br></div>
<div>
<div>with member [marital status].agg as 'Aggregate([marital status].[marital
status].members)'</div>
<div>select crossjoin( {Gender.Gender.M}, {[marital status].[marital
status].members, [marital status].agg} ) on 0, { measures.[profit
growth] } on 1 from sales;</div>
<div><br></div>
<div>This throws the exception:</div>
<div> mondrian.olap.fun.MondrianEvaluationException: Could not find an
aggregator in the current evaluation context</div>
<div><br></div>
<div><br></div>
<div>I'll look into it some more here, but I'm curious if anyone knows of
recent checkins that might be
responsible.</div></div></div></div></blockquote></div>
<br></div></div>_______________________________________________<br>
Mondrian mailing list<br>
<a href="mailto:Mondrian@pentaho.org" target="_blank">Mondrian@pentaho.org</a><br>
<a href="http://lists.pentaho.org/mailman/listinfo/mondrian" target="_blank">http://lists.pentaho.org/mailman/listinfo/mondrian</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br>