[Mondrian] question on "circular" MDX

John V. Sichi jsichi at gmail.com
Fri May 4 02:43:43 EDT 2007


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