<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6001.18226" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=027521522-09062009><FONT face="Lucida Sans" color=#000080
size=2>That makes sense. Please go ahead and add the tests, and fix the bug I
introduced.</FONT></SPAN></DIV>
<DIV><SPAN class=027521522-09062009><FONT face="Lucida Sans" color=#000080
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=027521522-09062009><FONT face="Lucida Sans" color=#000080
size=2>Julian</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000080 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Matt Campbell [mailto:mkambol@gmail.com]
<BR><B>Sent:</B> Tuesday, June 09, 2009 7:56 AM<BR><B>To:</B>
jhyde@pentaho.com; Mondrian developer mailing list<BR><B>Subject:</B> Re:
[Mondrian] Scoped solve order / Aggregate<BR></FONT><BR></DIV>
<DIV></DIV>
<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><FONT face="Lucida Sans" color=#000080 size=2></FONT><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">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>On Thu, Jun 4, 2009 at 9:11 PM, Julian Hyde <SPAN
dir=ltr><<A
href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<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 class=h5>
<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>_______________________________________________<BR>Mondrian
mailing list<BR><A
href="mailto:Mondrian@pentaho.org">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></BODY></HTML>