<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.18.3">
</HEAD>
<BODY>
<BR>
On Thu, 2008-10-30 at 15:54 -0700, Rushan Chen wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
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()?
</PRE>
</BLOCKQUOTE>
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"}.<BR>
<BR>
By comparison, the .ORDER_KEY property for these members would yield simple strings: "Savannah", "Albuquerque", "Atlanta", "Titusville".<BR>
<BR>
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.<BR>
<BR>
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:<BR>
<BR>
<A HREF="http://msdn.microsoft.com/en-us/magazine/cc794278.aspx">http://msdn.microsoft.com/en-us/magazine/cc794278.aspx</A> <BR>
<BR>
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.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
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).
</PRE>
</BLOCKQUOTE>
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.<BR>
<BR>
<PRE>
Julian
</PRE>
</BODY>
</HTML>