[Mondrian] question on "circular" MDX

Tue May 8 02:34:00 EDT 2007

Julian Hyde wrote:
> John,
> 
> I don't particularly care what the semantics are, as long as we adhere
> to the standard semantics. So I'm glad that you have found the
> definitive scripture on the issue.
> 
> Can you log a bug for #1: fix evaluation of calculated sets to use
> slicer-dependent semantics.
Done:
http://sourceforge.net/tracker/index.php?func=detail&aid=1714738&group_id=35302&atid=414613

> Is it possible to resolve #2 before the bug is fixed?
Yes, Rushan and I will poke around with MSAS some more to see if we can 
pin it down.

> All,
> 
> Let me know if changing to the correct semantics will break you.

We've implemented a temporary workaround, so we'll wait a bit to hear 
back from others.

> Julian
> 
>> -----Original Message-----
>> From: mondrian-bounces at pentaho.org 
>> [mailto:mondrian-bounces at pentaho.org] On Behalf Of John V. Sichi
>> Sent: Friday, May 04, 2007 2:08 PM
>> To: John V. Sichi
>> Cc: Mondrian developer mailing list
>> Subject: Re: Re : [Mondrian] question on "circular" MDX
>>
>> 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
>>>>
>>>
>>>
>> _______________________________________________
>> 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
> 