[Mondrian] question on "circular" MDX

John V. Sichi jsichi at gmail.com
Fri May 4 17:08:17 EDT 2007


Here's a quasi-official-sounding statement:

http://sqljunkies.com/WebLog/sqlbi/archive/2006/12/24/26337.aspx

It says that named sets defined in queries should be slicer-dependent, 
meaning:

1) Current behavior for non-native evaluation is incorrect (since it's 
coming out as slicer-independent, even though in the circular case it 
still manages to loop as if there were a dependency).

2) We need a resolution on the correct semantics for the original 
circular case.  Julian reported that MSAS 2000 did not reject the query, 
so the query processing it implements requires investigation and 
comparison with the current Mondrian native evaluation behavior, where 
the calculated members on the slicer are ignored in the NECJ.

JVS

John V. Sichi wrote:
> John V. Sichi wrote:
>> OK, good, that matches the code in NamedSetExpr, and what I see in SQL 
>> trace.
>>
>> Then the stack overflow in the non-native case must be due to some bug 
>> with juggling the calculated members.  I'll log it.
>>
>> JVS
>>
>> michael bienstein wrote:
>>> WITH SET ... is a named set.  Named sets are evaluated in the default 
>>> context - no slicer at all.
> 
> Well, turns out nothing is ever that simple.
> 
> Michael's statement above doesn't match MSAS 2000 behavior.  Run this 
> query:
> 
> with
> set [c] as '[Product].[All Product].[Drinks].[Flavored Drinks].children'
> set [p] as '{[Store].[All Store].[USA].[CA].children}'
> set [cp] as 'nonemptycrossjoin([c],[p])'
> select [cp] on columns
> from sales
> where ([Time].[1998])
> 
> Notice that the result includes a tuple for (Skinner, San Francisco).
> Now change the slicer to where ([Time].[1997]), and notice that this
> tuple disappears.  This is inconsistent with the named set evaluation
> being slicer-independent (since membership in the named set is what 
> should determine whether a tuple shows up on the axis, not whether it is 
> empty/nonempty with respect to the slicer).
> 
> So what are the correct semantics?  Mondrian currently can't make up its
> mind.  Run this query via cmdrunner with default settings (native
> crossjoin enabled):
> 
> with
> set [c] as [Product].[All Products].[Drink].children
> set [p] as {[Gender].[M]}
> set [cp] as nonemptycrossjoin([c],[p])
> select [cp] on rows
> from sales
> where ([Time].[1998]);
> 
> You will get back an empty rows axis (slicer-dependent behavior).  Then
> disable native crossjoin and run again, and you'll get back three tuples
> on the rows axis (slicer-independent behavior).
> 
> What is the "correct" behavior?
> 
> JVS
> 
>>> ----- Message d'origine ----
>>> De : John V. Sichi <jsichi at gmail.com>
>>> À : mondrian at pentaho.org
>>> Envoyé le : Dimanche, 4 Février 2007, 3h50mn 51s
>>> Objet : [Mondrian] question on "circular" MDX
>>>
>>> If I run the query below with native crossjoins enabled, it comes back
>>> with an answer.  But if I run it with
>>> mondrian.native.crossjoin.enable=false, it fails with a stack overflow.
>>>   There's clearly a bug, in that the behavior should be the same
>>> regardless of the implementation.  And if it should fail, it would be
>>> nice to fail with a validation error regarding the circularity (rather
>>> than a stack overflow).
>>>
>>> The cycle in the non-native case is as follows.  The calculated members
>>> in the slicer depend on named set CJ, the result of some
>>> NonEmptyCrossJoins.  But those NECJ's in turn depend on the slicer for
>>> deciding non-emptiness of each candidate tuple.
>>>
>>> There's some further problem with the calculated member manipulation in
>>> that it requires two calculated members to fail; with just one
>>> calculated member in the slicer, it succeeds regardless of whether
>>> native crossjoin is used.  Unless I'm misunderstanding the cause of the
>>> problem, if it's going to fail in one case, it should fail in the other.
>>>
>>> Any opinions on the correct behavior?
>>>
>>> with
>>> set BM_PRODUCT as {[Product].[All Products].[Drink]}
>>> set BM_EDU as [Education Level].[Education Level].Members
>>> set BM_GENDER as {[Gender].[Gender].[M]}
>>> set CJ as 
>>> NonEmptyCrossJoin(BM_GENDER,NonEmptyCrossJoin(BM_EDU,BM_PRODUCT))
>>> set GM_PRODUCT as Generate(CJ, {[Product].CurrentMember})
>>> set GM_EDU as Generate(CJ, {[Education Level].CurrentMember})
>>> set GM_GENDER as Generate(CJ, {[Gender].CurrentMember})
>>> set GM_MEASURE as {[Measures].[Unit Sales]}
>>> member [Education Level].FILTER1 as Aggregate(GM_EDU)
>>> member [Gender].FILTER2 as Aggregate(GM_GENDER)
>>> select
>>> GM_PRODUCT on rows,
>>> GM_MEASURE on columns
>>> from [Sales]
>>> where ([Education Level].FILTER1, [Gender].FILTER2);
>>>
>>> JVS
>>> _______________________________________________
>>> Mondrian mailing list
>>> Mondrian at pentaho.org
>>> http://lists.pentaho.org/mailman/listinfo/mondrian
>>>
>>>
>>> ------------------------------------------------------------------------
>>> Découvrez une nouvelle façon d'obtenir des réponses à toutes vos 
>>> questions ! Profitez des connaissances, des opinions et des 
>>> expériences des internautes sur Yahoo! Questions/Réponses 
>>> <http://fr.rd.yahoo.com/evt=42054/*http://fr.answers.yahoo.com>.
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Mondrian mailing list
>>> Mondrian at pentaho.org
>>> http://lists.pentaho.org/mailman/listinfo/mondrian
>>
>>
> 
> 
> 




More information about the Mondrian mailing list