[Mondrian] MONDRIAN-936

Matt Campbell mkambol at gmail.com
Wed Jan 23 16:41:42 EST 2013


Thanks for the feedback.  Compound slicers seem inherently messy to me
considering some of these cases.  Analysis Services moved to
subselects/subcubes as the preferred method of multi-selection, which has
clearer semantics.  AFAIK Excel is the only client that ever implemented
support for subselects in MDX, though.

I’ve created 2 defects- one for .CurrentMember and one for the case where
multiple measures appear in the compound slicer.  That really shouldn’t be
allowed, either.

MONDRIAN-1398 <http://jira.pentaho.com/browse/MONDRIAN-1398>

MONDRIAN-1399 <http://jira.pentaho.com/browse/MONDRIAN-1399>




On Tue, Jan 22, 2013 at 8:38 PM, Julian Hyde <jhyde at pentaho.com> wrote:

> (Taking this discussion public.)
>
> On Jan 22, 2013, at 3:18 PM, Matt Campbell <mcampbell at pentaho.com> wrote:
>
> I’ve done some more testing with the change we discussed in Monday’s
> hangout—i.e. swapping out the slicer axis set with a dummy placeholder when
> a compound slicer is present, after the aggregate calc for the slicer set
> has been created and pushed to the evaluator.  This change would be in the
> RolapResult constructor in the “Execute Slicer” section.  The change
> produces correct results for the use case described in MONDRIAN-936, and
> addresses other cases where multiple calculated members are present in the
> slicer.  It also appears to jive well with native constraint evaluation and
> causes no failed tests in the suite.  I’m still not sure if it’s the best
> solution, though, and I’ve been looking through the other slicer related
> bugs to see whether we might be painting ourselves into a corner.****
>
> There are several Jira cases involving the slicer incorrectly overriding
> calculated members on the axes.  For example:****
>
> with member measures.[Store Sales Q1] as '(measures.[Store Sales],
> [Time].[1997].[Q1])'****
> select { measures.[Store Sales], measures.[Store Sales Q1] } on 0 from
> sales where****
> { [Time].[1997].[Q2],[Time].[1997].[Q3] }****
>
> This query will override the [Q1] context of the [Store Sales Q1] measure,
> and both measures end up having the same value (the rollup of [Q2] and
> [Q3]).  This is similar to MONDRIAN-824, 1226 and 1095.****
>
> MONDRIAN-555 also seems important- that’s the one about potential over
> count with compound slicers (if you do something like slice on
> {[Product].[Food], [Product].[Food].[Cheese]}, for example. ****
>
> Another case I was thinking about involves .CurrentMember.  CurrentMember
> really doesn’t make sense when applied to any dimension that also appears
> in a compound slicer.  Analysis Services explicitly prevents this and gives
> an error.  Right now Mondrian will evaluate CurrentMember to be the member
> from the first tuple in the slicer set.  E.g. in the following query
> Time.CurrentMember evaluates to [Q4].****
>
> with member measures.[drink sales previous period] as****
> '( Time.CurrentMember.lag(1), [Product].[All Products].[Drink],
> measures.[unit sales] )'****
> member measures.[drink sales current period] as****
> '( Time.CurrentMember, [Product].[All Products].[Drink], measures.[unit
> sales] )'****
> select { measures.[drink sales previous period], measures.[drink sales
> current period] } on 0 from sales****
> where { [Time].[1997].[Q4],[Time].[1997].[Q3] }****
>
> It’s not clear to me whether the change I suggested for MONDRIAN-936 will
> get us closer to a solution to these other problems, or whether it will end
> up being at odds.  Julian- in MONDRIAN-555 you describe an alternate
> implementation that views the tuples in the slicer set as a collection of
> predicates pushed to the WHERE.  Is that something we should be thinking
> about?
>
>
> I don't think that MONDRIAN-555 is that important. I mean, not important
> enough that it should influence the architecture. I logged the bug for full
> disclosure. Let's choose the architecture that works for the "80%" cases,
> and we can find a workaround that makes 555 work.
>
> An MDX "WHERE" clause should be evaluated like predicates.
>
>   MDX: WHERE {[Foo].[X], [Foo].[Y]}
>
> should be similar to
>
>   SQL: WHERE foo = 'X' OR foo = 'Y'
>
> It's difficult to evaluate
>
>   MDX: WHERE {[Foo].[X], [Foo].[Y], [Foo].[X]}
>
> in the same way, but much less important.
>
> I agree that .CurrentMember should give an error when invoked on composite
> members in the slicer. (It's like asking Shroedinger's cat whether it's
> alive.) The error should allow people to realise they are doing something
> dumb quicker. Can you log a jira case for it, please?
>
> I don't know exactly what you mean by "swapping out the slicer axis set
> with a dummy placeholder when a compound slicer is present" but it sounds
> like the right thing. If it tends to work well with both native SQL and
> in-memory evaluation then it is undoubtedly the right solution.
>
> FWIW, I have a real problem with "List<Member> slicerMembers" in
> RolapEvaluator. This implies that the slicer is flat (i.e. at most one
> member per hierarchy) which it most definitely isn't. Any code that relies
> on that member is probably suspect.
>
> Julian
>
>
> _______________________________________________
> 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/20130123/6ac772a2/attachment.html 


More information about the Mondrian mailing list