[Mondrian] Compound Slicer Solve Order and Distinct Count Measures

Julian Hyde julianhyde at gmail.com
Mon Jul 28 14:49:33 EDT 2014

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?


On Jul 25, 2014, at 3:21 PM, Will Gorman <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
> http://lists.pentaho.org/mailman/listinfo/mondrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20140728/6e95c179/attachment.html 

More information about the Mondrian mailing list