[Mondrian] Re: Eigenbase perforce change 11758 for review

[Rushan Chen]

Hi Julian,

I see your suggestions regarding using a set of values along the 
hierarchy to compare member hierarchically. It will solve the DESC/ASC 
issue so that client does not need to enumerate the keys from parent levels.

However, I think this still does not address the issue of supporting 
existing member comparison semantics (see FunUtil.compareSiblingMembers()):

(1) Calculated members collate greater than stored members; 
non-determined if compared with another calculated member.
(2) If two members do not have order key value, compare by ordinals and 
if they are the same, compare by member unique name.

To support the above for a set of members from a single level dimension, 
should the ordinal returned be a compound also? The compound will need 
to include information on : (1) calculated vs non,  (2) order key or 
ordinal,  (3) member unique name.

Please let me know if discussing this offline is more efficient.

Rushan

Julian Hyde wrote:
>
> On Thu, 2008-10-30 at 15:54 -0700, Rushan Chen wrote:
>> What I was referring to by "multiple values" is the fact that the 
>> existing sort implicitly compares several properties associated with a 
>> member. See FunUtil.compareSiblingMembers(). This cannot be replicated 
>> using just one scalar value as the key. The presence of calculated 
>> members also makes assigning key difficult because they compare 
>> differently from stored members.
>>
>> Suppose we are sorting on members from a  single level dimension, what 
>> combinations of properties/keys can be used to mimic the behavior in 
>> FunUtil.compareSiblingMembers()?
>>
>>     
> I agree that scalar values are not sufficient to achieve hierarchical 
> sort behavior. That's why my proposed .ORDINAL property returns a 
> compound value. For [USA].[GA].[Savannah] it would return the list 
> {"Savannah", "GA", "USA"}, or an equivalent Comparable that would 
> collate before {"Albuquerque", "NM", "USA"} but after {"Atlanta", 
> "GA", "USA"} and {"Titusville", "FL", "USA"}.
>
> By comparison, the .ORDER_KEY property for these members would yield 
> simple strings: "Savannah", "Albuquerque", "Atlanta", "Titusville".
>
> I know that MDX doesn't support compound values like this, but the 
> value would be produced and consumed within the sort routine. If 
> anyone was foolish enough to try to display it, they would just see a 
> string representation.
>
> But what I'm doing is not completely unprecedented. SQL Server has 
> introduced a new data type, HierarchyID, which elegantly solves some 
> of the problems of dealing with hierarhical data in a RDBMS:
>
> http://msdn.microsoft.com/en-us/magazine/cc794278.aspx
>
> What I'm proposing isn't exactly the same, and I won't elevate it to 
> an official data type, but it uses the same thinking.
>
>> Regarding the disparity between members and measures in sort key 
>> evaluation, is it possible to use some other indicators to tell the 
>> function how to interpret the input argument type? We considered using 
>> special key words in the sort direction(KDESC, KASC for example), or to 
>> group the member references together, like what generate function 
>> does(this will limit where in the sort key a measure can appear though).
>>     
> It might be possible. But I'm convinced that we can achieve all sort 
> behavior - including hierarchical and non-hierarchical sorts - by 
> making everything an MDX expression. So I'd rather not introduce a new 
> value type.
>
> Julian
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>