[Mondrian] MONDRIAN-936

[Paul Stoellberger]

We talked about that a while ago and I'm a big fan of subselects for that matter. It could also be used for roles etc.
I would be happy to implement subselects in the olap4j query model and therefore saiku in case anyone wants to develop the support for it in mondrian! ;-)

-Paul


On Jan 23, 2013, at 10:41 PM, Matt Campbell wrote:

> 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
> 
> 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
> 
> 
> _______________________________________________
> 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/20130125/6bdf6e64/attachment.html