<!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 Tue, 2008-10-28 at 14:46 -0700, Rushan Chen wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi Julian,
We have in fact discussed the exact same comment as yours regarding
CollationKey. The wiki section below is now expanded with some more details:
<A HREF="http://pub.eigenbase.org/wiki/MondrianOrderFunctionExtension#Syntax_Options">http://pub.eigenbase.org/wiki/MondrianOrderFunctionExtension#Syntax_Options</A>
In short, CollationKey is eventually not chosen because
(1) Existing sort orders by several keys implicitly, which can not be
replicated using CollationKey(or Order_Key as in your suggestion).
</PRE>
</BLOCKQUOTE>
<BR>
I think that you can sort by several keys simultaneously using ORDER.<BR>
<BR>
Here is an example that sorts customers by the name of their state (but not country), then by the name of their city, then by the amount of beer they purchased in 2007.<BR>
<BR>
ORDER(<BR>
[Customer].MEMBERS, <BR>
BASC,<BR>
Ancestor([Customer], [Customer].[State]).ORDER_KEY,<BR>
BASC,<BR>
Ancestor([Customer], [Customer].[City]).ORDER_KEY,<BR>
BASC,<BR>
([Measures].[Unit Sales], [Product].[Beer], [Time].[2007]),<BR>
BDESC)<BR>
<BR>
<BR>
<PRE>
Nation State City Name Unit Sales
-------- ----- ------- -------- ----------
USA AR Fred 100
Russia GA Tblisi Vladimir 200
USA GA Atlanta Bill 300
USA GA Savanah Eric 400
USA GA Savanah Jane 350
</PRE>
If someone wanted to sort customers by their city hierarchically (i.e. city within state within nation) then they should be able to write<BR>
<BR>
ORDER(<BR>
[Customer].MEMBERS,<BR>
BASC,<BR>
Ancestor([Customer], [Customer].[City]).ORDINAL,<BR>
([Measures].[Unit Sales], [Product].[Beer], [Time].[2007]),<BR>
BDESC)<BR>
<BR>
For [USA].[GA].[Atlanta], ORDINAL would return the compound object {"Atlanta", "GA", "USA"}.<BR>
<BR>
Can you give me a counterexample that cannot be represented using ORDER with multiple sort expressions, and properties .ORDER_KEY and .ORDINAL?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
(2) Hierarchical comparison can not be supported. Client will use
BASC/BDESC on all ancestor levels to mimic ASC/DESC.
</PRE>
</BLOCKQUOTE>
I agree that it doesn't make sense if the expressions have different 'break' behavior. The above example would be confusing if it was say {BASC, ASC, DESC} instead of {BASC, BASC, BDESC}. The ORDER function should give an error if ASC/DESC are mixed with BASC/BDESC.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Regarding the MDX design principle of not evaluating member to (the
same) member, I think the violation can be avoided using
LevelExpressions(as in the very first proposal):
OrderSet(<set>, [Dimension].[level], ..., [Measures].[m1])
</PRE>
</BLOCKQUOTE>
<BR>
Yes, but it is simpler if all we ever sort on is expressions. I think I have demonstrated that, with the new .ORDER_KEY and .ORDINAL properties, expressions are sufficient for all sorting behavior.<BR>
<BR>
Sorting by levels would be troublesome because they are not sufficiently different from expressions. Although mondrian does not implicitly convert levels into members (unlike hierarchies and dimensions), a lot of people expect it to treat them like expressions. And I believe that AS2005 does convert levels into expressions.<BR>
<BR>
Julian<BR>
<BR>
</BODY>
</HTML>