[Mondrian] MEMBER_ORDINAL: fubar when combined with nativefiltering?

John V. Sichi jsichi at gmail.com
Tue Feb 20 20:37:56 EST 2007

I'm going to check in a limited fix for this.  Julian, since this is 
potentially destabilizing, I'm going to check it in with a property 
disabling it by default; it will be necessary to explicitly enable the 
property to get the fix.  I will leave it up to you about when it is 
safe to permanently enable it, and what to do about whether to fix the 
broken absolute ordinals; the link below says 
MDSCHEMA_MEMBERS.MEMBER_ORDINAL is deprecated in MSAS 2005 and always 
returns 0.  There's a bunch of code in RolapMember devoted to setting 
them for XML/A support.


Also, if you would prefer that I instead check into //open/lu/mondrian 
and integrate it up to //open/mondrian only after the Mondrian release, 
let me know.

Here's what I'm planning to do:

1.  Add a new attribute orderKey (of type Comparable) in RolapMember.

2.  Change SqlMemberSource to populate orderKey (when new property 
mondrian.rolap.compareSiblingsByOrdinalKey is true; default false).

3.  Change FunUtil.compareSiblingMembers to compare based on orderKey 
when not null, otherwise revert to current behavior (first on buggy 
getOrdinal(), then on member.compareTo).

4.  The comments on RolapMember.compareTo indicate that I shouldn't need 
to make any changes there.

Where does the potential destabilization come from?

Previously (for non-buggy cases) the ordering was entirely determined by 
the implementation of ORDER BY in the underlying DBMS, since this is 
what the assignment of absolute ordinals was based on.  Now it will be 
determined by retrieving the column value and (in some cases) calling 
compareTo on the returned value.  I say "in some cases" because it looks 
like member.children is relying on the fetch order of the child array, 
whereas level.members is relying on FunUtil.hierarchize.  So, existing 
behavior could change, possibly becoming inconsistent or failing due to 
return of non-Comparable values, or nulls, or untrimmed strings, or...


John V. Sichi wrote:
> Julian Hyde wrote:
>> 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
>> datatype).
>> Does that scheme seem to make sense? If so, please log a bug.
> Yes.  Logged as
> https://sourceforge.net/tracker/?func=detail&atid=414613&aid=1660383&group_id=35302 

More information about the Mondrian mailing list