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

[Julian Hyde]

John,

This change sounds like an improvement. If you can check in the change in
the next day or so (disabled by default) I will run it through the full
regression suite. If nothing seems broken, I will enable this change for
RC1.

Please update schema.html to match the new semantics. I will back out
schema.html if I decide not to include the new behavior in RC1.

Julian 

> -----Original Message-----
> From: mondrian-bounces at pentaho.org 
> [mailto:mondrian-bounces at pentaho.org] On Behalf Of John V. Sichi
> Sent: Tuesday, February 20, 2007 5:38 PM
> To: Mondrian developer mailing list
> Subject: Re: [Mondrian] MEMBER_ORDINAL: fubar when 
> combinedwith nativefiltering?
> 
> 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.
> 
> http://msdn2.microsoft.com/en-us/library/ms143235.aspx
> 
> 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...
> 
> JVS
> 
> 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=1
> 660383&group_id=35302 
> > 
> > 
> > JVS
> > 
> 
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>