[Mondrian] LastNonEmpty and slicers problem

Tiago Santos tiago.santos at cortex-intelligence.com
Thu Oct 16 16:55:15 EDT 2014


Thank you for the heads up. I'll take a look.
On Oct 16, 2014 8:55 PM, "Matt Campbell" <mcampbell at pentaho.com> wrote:

>  Hi Tiago-
>
>
>
> You’ve identified the basic problem:  named sets are evaluated before the
> special compound slicer member has been pushed into context.  I’m not
> really sure what the best fix is, though.  Regenerating the compound slicer
> member with every call of evaluateExp is probably not what we’d want to
> do.  IIRC, Will Gorman had done some work awhile back on addressing this
> issue.  I think he’d done some rearranging of evaluation order in the
> constructor.
>
>
>
>
>
> *From:* mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org]
> *On Behalf Of *Tiago Santos
> *Sent:* Thursday, October 16, 2014 2:14 PM
> *To:* Mondrian developer mailing list
> *Subject:* Re: [Mondrian] LastNonEmpty and slicers problem
>
>
>
> Hi Matt,
>
> I've been playing around this issue for a while and, in our case, have
> come to a solution.
>
> Based in your hints I've look at RolapResult at evaluateExp and implemented
> the same behavior defined in the constructor when executing the slicer
> part, and put it in the evaluateExp method.
>
> It seems to have fixed the issue, but I haven't run any tests to see if
> breaks anything (I believe not).
>
>
>
> Any thoughts ?
>
>
>
> the new evaluateExp
>
>
>
>
>
>
>
>
>
> Object evaluateExp(
>
>         Calc calc,
>
>         RolapEvaluator slicerEvaluator,
>
>         Evaluator contextEvaluator)
>
>     {
>
>         int attempt = 0;
>
>
>
>         RolapEvaluator evaluator = slicerEvaluator.push();
>
>         if (contextEvaluator != null && contextEvaluator.isEvalAxes()) {
>
>             evaluator.setEvalAxes(true);
>
>             evaluator.setContext(contextEvaluator.getMembers());
>
>         }
>
>
>
>         // Copied from constructor
>
>         final TupleList tupleList =
> TupleCollections.asTupleList(evaluator.getSlicerMembers());
>
>         if (tupleList.size() > 1) {
>
>             final Calc valueCalc = new ValueCalc(new DummyExp(new
> ScalarType()));
>
>             final Calc calc1 =
>
>                     new GenericCalc(
>
>                             new DummyExp(query.slicerCalc.getType()))
>
>                     {
>
>                         public Object evaluate(Evaluator evaluator) {
>
>                             TupleList list =
>
>                                     AbstractAggregateFunDef
>
>                                             .processUnrelatedDimensions(
>
>                                                     tupleList, evaluator);
>
>                             return AggregateFunDef.AggregateCalc.aggregate(
>
>                                     valueCalc, evaluator, list);
>
>                         }
>
>                     };
>
>
>
>             // replace the slicer set with a placeholder to avoid
>
>             // interaction between the aggregate calc we just created
>
>             // and any calculated members that might be present in
>
>             // the slicer.
>
>             // Arbitrarily picks the first dim of the first tuple
>
>             // to use as placeholder.
>
>             Member placeholder = setPlaceholderSlicerAxis(
>
>                     (RolapMember) tupleList.get(0).get(0), calc1);
>
>             evaluator.setContext(placeholder);
>
>         }
>
>         // Rest of the code
>
>         .....
>
>
>
>
>
>
>
> 2014-10-14 16:52 GMT+01:00 Matt Campbell <mcampbell at pentaho.com>:
>
>  I believe the 2 workarounds are to either inline the named set directly
> on the axis, or use a calculated member that aggregates the set you’re
> currently using in the slicer, and place that calculated member in the
> slicer instead.  E.g.
>
>
>
> With member
>
> Product.agg as ‘ Aggregate( {[product].[product].[a],
> [product].[product].[c]})’
>
> Select
>
> ….
>
> WHERE
>
> ( product.agg )
>
>
>
>
>
> HTH
>
>
>
> *From:* mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org]
> *On Behalf Of *Hilario Fernandes
> *Sent:* Tuesday, October 14, 2014 11:42 AM
> *To:* Mondrian developer mailing list
> *Subject:* Re: [Mondrian] LastNonEmpty and slicers problem
>
>
>
> Hey Matt,
>
>
>
> Thanks for the reply! I've put the set directly on the axis and it works
> as expected. I've added the information on the issue you pointed out and
> voted! Guess there's nothing else i can do at the moment... I'm going to
> try and find a workaround of some sort...
>
>
>
> On Tue, Oct 14, 2014 at 1:28 PM, Matt Campbell <mcampbell at pentaho.com>
> wrote:
>
>
>
> Hi Hilario,
>
> There’s a known issue with named set evaluation in the context of a
> compound slicer (MONDRIAN-1654).  Can you try moving the [date] set
> directly onto the row axis to see whether you get expected numbers?  And if
> that *is* your issue, vote and/or comment on the case.  I’d love to see
> it get addressed.
>
>
>
> Matt
>
>
>
>
>
> *From:* mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org]
> *On Behalf Of *Hilario Fernandes
> *Sent:* Monday, October 13, 2014 12:43 PM
> *To:* Mondrian mailing list
> *Subject:* [Mondrian] LastNonEmpty and slicers problem
>
>
>
> Hi,
>
>
>
> I'm experiencing a weird behaviour while using the LastNonEmpty function.
> My MDX is as follows:
>
>
>
> WITH
>
> SET [date] AS
>
> {LastNonEmpty([date.YEAR].[YEAR].Members, [Measures].[measure_SUM])}
>
>
>
> SELECT
>
> NON EMPTY {[Measures].[measure_SUM]} ON COLUMNS,
>
> NON EMPTY {[date]} ON ROWS
>
>
>
> FROM [cube]
>
> WHERE {[product].[product].[a], [product].[product].[c]}
>
>
>
> The schema:
>
>
>
> <Cube name='cube' visible='true' cache='true' enabled='true'>
>
>   <Table name='CUBE_609d989076e048e2a9ee831bdeaee2b3_FACT'
> alias='FACT_252ad422f6ae474fb25001f7586bdbd2' />
>
>    <Dimension name='product' caption='product' visible='true'>
>
>     <Hierarchy name='product' caption='product' allMemberName='Total
> product' visible='true' hasAll='true'>
>
>       <Level name='product' caption='product' visible='true'
> column='ATTR_c7a295ae3dfa4af9acaacc56fc16c276' uniqueMembers='true'
> levelType='Regular' hideMemberIf='Never' type='String' />
>
>     </Hierarchy>
>
>   </Dimension>
>
>   <DimensionUsage name='date' source='Shared Date' caption='date'
> visible='true' foreignKey='DIM_ID_b6c96b55efdd430b8b991d20f6eef622' />
>
>   <Measure caption='measure_SUM' name='measure_SUM'
> column='MEASURE_bfe8f487ff6846b58195028020207647' formatString='Standard'
> aggregator='sum' />
>
> </Cube>
>
>
>
> and the data:
>
>
>
> product, date, measure
>
> a,2014-01-01, 10
>
> b,2014-01-01, 20
>
> c,-,null
>
>
>
> The problem is i'd expect the above query to return the sum of the measure
> for the year 2014, considering the slicers, but it doesn't. Seems like the
> slicers aren't being properly applyed, and only the last of the set is
> considered during LastNonEmpty evaluation. In this case it returns nothing,
> because the measure is null for [product].[product].[c].
>
>
>
> Is this a known problem or am i doing something wrong? I've been debugging
> mondrian code trying to understand what's going on hoping to narrow the
> problem and it seems to be related to LastNonEmpty.
>
>
>
> I appreciate any help! Thank you!
>
>
>
>
>
> --
>
> Hilario Fernandes
>
>
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>
>
>
>
>
> --
>
> Hilario Fernandes
>
>
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>
>
>
>
>
> --
>
> [image: logo-cortex-rgb (menor)]
>
> *Tiago Santos*
>
> tiago.santos at cortex-intelligence.com
>
> Tm  +351 910 599 751
>
> *www.cortex-intelligence.com* <http://www.cortex-intelligence.com/>
>
> Consultoria | Tecnologia | Outsourcing
>
> _______________________________________________
> 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/20141016/fffd778d/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2324 bytes
Desc: not available
Url : http://lists.pentaho.org/pipermail/mondrian/attachments/20141016/fffd778d/attachment-0001.gif 


More information about the Mondrian mailing list