[Mondrian] Re: Eigenbase perforce change 11758 for review

Julian Hyde jhyde at pentaho.com
Fri Oct 31 14:25:22 EDT 2008


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20081031/2d3ea72c/attachment.html 


More information about the Mondrian mailing list