[Mondrian] MEMBER_ORDINAL: fubar when combined with nativefiltering?

Julian Hyde julianhyde at speakeasy.net
Thu Feb 15 03:46:43 EST 2007

No good reason. I think I've known for a few years, at the back of my mind,
that this ordinal scheme is broken.

Space may have been a consideration at one point, but it isn't valid now,
because members take up quite a lot of space.

I think it would be a mistake to try to construct MEMBER_ORDINAL out of
strings, first because it might confuse clients, and second because
concatenated string keys tend to sort incorrectly (consider "2007:2:15",

When writing the schema guide, I should have clearly distinguished absolute
ordinal (an integer which identifies the position of a member within its
dimension) from an ordinal property which may be any datatype and identifies
a member's order within its parent. If I had done that, I would have
realised that we need two attributes in the schema: ordinal (an integer,
unique for members of all levels in a hierarchy) and orderKey (any

Does that scheme seem to make sense? If so, please log a bug.


> -----Original Message-----
> From: mondrian-bounces at pentaho.org 
> [mailto:mondrian-bounces at pentaho.org] On Behalf Of John V. Sichi
> Sent: Wednesday, February 14, 2007 10:10 PM
> To: mondrian at pentaho.org
> Subject: [Mondrian] MEMBER_ORDINAL: fubar when combined with 
> nativefiltering?
> 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.
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian

More information about the Mondrian mailing list