[Mondrian] question on "circular" MDX

Julian Hyde julianhyde at speakeasy.net
Mon May 7 19:51:36 EDT 2007


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.

Is it possible to resolve #2 before the bug is fixed?

All,

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

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
> 




More information about the Mondrian mailing list