[Mondrian] question on "circular" MDX

[Julian Hyde]

I agree it's a bug, because the behaviors are inconsistent, and because if
we're going to issue an error it should be at validate time.

I can't figure out just yet what the correct behavior should be. One of the
factors is that NonEmptyCrossJoin is being called in the slicer, which seems
dubious; the other, as you point out, is that a set is being invoked in the
slicer whose value depends (via NonEmptyCrossJoin) on the output of the
slicer.

I need to do some more research into the behavior of the weird and wonderful
NonEmptyCrossJoin function.

I note that MSAS 2000 does not give an error; it returns

           Unit Sales
========== ==========
Drink          961.00

(To make the query work in MSAS 2000, you also have to enclose each formula
in single-quotes.)

Can you log it please?
http://sourceforge.net/tracker/?group_id=35302&atid=414613

Julian


> -----Original Message-----
> From: mondrian-bounces at pentaho.org 
> [mailto:mondrian-bounces at pentaho.org] On Behalf Of John V. Sichi
> Sent: Saturday, February 03, 2007 6:51 PM
> To: mondrian at pentaho.org
> Subject: [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
>