[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
>> ordinal (an integer which identifies the position of a member within its
>> dimension) from an ordinal property which may be any datatype and
>> 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.
> Yes. Logged as
More information about the Mondrian