<!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>
On Fri, 2008-10-31 at 15:50 -0700, Rushan Chen wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
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.
</PRE>
</BLOCKQUOTE>
<PRE>

</PRE>
Rushan,<BR>
<BR>
We're at odds because we're coming at this from two different directions. I'm trying to establish whether Order(&lt;list expr&gt;, {&lt;sort expr&gt;, &lt;flag&gt;}...) is capable of expressing any form of sort we need. And you're trying to establish that it can be implemented efficiently.<BR>
<BR>
Obviously I don't want to saddle us with a specification that is impossible to implement efficiently - or impossible to implement period. But also I don't want to make the MDX language more complicated for the end-user because we are driven by how things are working internally.<BR>
<BR>
I haven't heard any cases that Order can't handle - when combined with .Order_key and .Ordinal. But you point out some complexities of the implementation that I hadn't thought of.<BR>
<BR>
I think the implementation details can be worked out. As you point out, if we explicitly instantiate this compound value, we would need to include whether it is calculated, the ordinal, and the unique member name in order to make the logic work. We probably wouldn't instantiate this compound value explicitly: we would return a Comparable object which has a 'Comparable getParent()' method which creates the next object if the previous comparison has yielded 0. Or, we could recognise patterns like Order(&lt;set&gt;, &lt;dimension&gt;.CurrentMember.Order_Key) and Order(&lt;set&gt;, &lt;dimension&gt;.CurrentMember.Ordinal) and translate them into code that never actually calls Ordinal or Order_Key at all - code in fact very similar to the code you have already written.<BR>
<BR>
Do you think that any of those implementations could be made to work?
<PRE>
Julian
</PRE>
</BODY>
</HTML>