[Mondrian] Compound Slicer Solve Order and Distinct Count Measures

Matt Campbell mcampbell at pentaho.com
Thu Jul 31 09:17:49 EDT 2014


In Analysis Services 2000 if a calculated member containing an Aggregate() function had a higher solve order than what it was evaluating, AS would throw an error. It did this because there is no generic way of determining how to aggregate over a calculated member. Mondrian gives the error "Could not find an aggregator in current context" when it hits this.  Mondrian can't know the appropriate aggregator for non-base measures.  SSAS2005+ built in some smarts to aggregate the base components of an expression, which avoids tripping over SOLVE_ORDER.  I think it would be ideal if Mondrian moved toward that as well.  I don't think this has been much of an issue to date, though, because in most cases it's possible for cube developers and client tools to simply define their SOLVE_ORDERS such that Aggregate() expressions have the lowest solve order (Analyzer, for example, sets solve order to -100 for Aggregate)

In the case of compound slicers, we create an aggregate calc behind the scenes, and currently assign  it a solve order of 0.   As Will points out, this causes issues if there's anything that happens to be evaluated afterwards.

I'd suggest setting it to a value of Integer.MIN_VALUE.  I can't think of a reason to make it configurable.


From: mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org] On Behalf Of Julian Hyde
Sent: Monday, July 28, 2014 2:50 PM
To: Mondrian developer mailing list
Subject: Re: [Mondrian] Compound Slicer Solve Order and Distinct Count Measures

What is the value of CompoundSlicerSolveOrder that makes behavior compatible with SQL Server Analysis Services? In other words, are we changing behavior by making -1000 the default?

Julian

On Jul 25, 2014, at 3:21 PM, Will Gorman <wgorman at pentaho.com<mailto:wgorman at pentaho.com>> wrote:


Hi folks,

I've been working with compound slicers lately, and have a proposal for the team.  My most recent case that I came across is here:

http://jira.pentaho.com/browse/MONDRIAN-2156

This example highlights some issues around the Aggregate function's handling of distinct count measures, it should definitely be fixed.  But a workaround that prevents these problems from occurring that has been very effective in our environment is setting the solve_order of the calculated compound slicer member to a very small number (in my case I set it to -1000).  It's value is 0 without my change, and often times in our scenarios having solve order be the default as other calculated measures, especially if they appear later in the cube ordinal order, can cause havoc with our results.

I propose that we either change the hardcoded value from 0 to -1000, or we introduce a new property in mondrian.properties such as  "mondrian.rolap.CompoundSlicerSolveOrder=-1000".  With the new property, we can ensure backwards compatibility, setting the default to 0 if that's what people prefer.

Let me know what you think!

Will
_______________________________________________
Mondrian mailing list
Mondrian at pentaho.org<mailto: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/20140731/bd4fdc82/attachment.html 


More information about the Mondrian mailing list