[Mondrian] MEMBER_ORDINAL: fubar when combined with native filtering?

John V. Sichi jsichi at gmail.com
Thu Feb 15 01:10:08 EST 2007


Is there a good reason Mondrian attempts to map the ordinal expression 
into an absolute numeric ordinal?  Because from what I can tell, this 
doesn't work unless you manage to fully prime the level cache in order 
to get the ordinals set correctly.  If you do any native filtering, 
leading the cache to get populated incrementally, the assignment of 
lastOrdinal within SqlMemberSource is wrong.  Wouldn't it make more 
sense to preserve the expression as a non-numeric ordinal key which 
could be compared without knowing the full extent?

I realize that this could take more space in the cache depending on the 
datatype, but if the dimension is small, that's not so bad, and if the 
dimension is large, it's much better than being forced to pin the whole 
thing just to be able to assign absolute ordinals.  MOLAP dimension 
processing solves this, but...

To see the problem, run this:

with
member [Measures].[o] as
[Customers].[Name].currentmember.Properties("MEMBER_ORDINAL")
set necj as nonemptycrossjoin(
[Store].[Store State].members, [Customers].[Name].members
)
select tail(necj,5) on rows,
{[Measures].[o]} on columns
from [Sales];

and then this:

with member [Measures].[o] as
[Customers].[Name].currentmember.Properties("MEMBER_ORDINAL")
select tail([Customers].[Name].members, 5)
on rows,
{[Measures].[o]} on columns
from [Sales];

The first one partially fills the cache (assigning incorrect absolute 
ordinals, although they are correctly ordered within the scope of that 
query), and then the second one shows the mismatch across queries.

Of course, if you set both mondrian.native.crossjoin.enable=false and 
mondrian.native.nonempty.enable=false, you get correct results for both.

JVS



More information about the Mondrian mailing list