[Mondrian] Re: Eigenbase perforce change 11758 for review

[Rushan Chen]

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:
http://pub.eigenbase.org/wiki/MondrianOrderFunctionExtension#Syntax_Options

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).
(2) Hierarchical comparison can not be supported. Client will use 
BASC/BDESC on all ancestor levels to mimic ASC/DESC.

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])


The changes to implementation should be minimal regardless. Please 
comment on these ideas so that we can get it to the final shape quickly.

Rushan

Julian Hyde wrote:
>
>
> On Tue, 2008-10-21 at 00:01 -0700, Rushan Chen wrote:
>> Hi Julian,
>>
>> Thought I could chime in as I posted the original suggestion for syntax 
>> extension, which is turning out to be a different function in its final 
>> shape.
>>
>> An earlier post here asked for inputs for the syntax options considered:
>> http://lists.pentaho.org/pipermail/mondrian/2008-October/001473.html
>> (The URL it refers to should be 
>> http://pub.eigenbase.org/wiki/MondrianOrderFunctionExtension#Syntax_Options) <http://pub.eigenbase.org/wiki/MondrianOrderFunctionExtension#Syntax_Options%29>
>>
>> After a few days without new use cases that supports the alternative 
>> syntax, we decided on adopting a new function name because it is the 
>> least entangled with the existing Order function and its implementation.
>>
>> Rushan
>>     
> I have just read the discussion about CollationKey vs. OrderSet and I 
> am strongly in favor of CollationKey. I would call it ORDER_KEY, 
> because collation connotes NLS.
>
> Example. The ORDER_KEY property is similar to ORDINAL but only applies 
> to the current level. E.g. [Time].[2008].[October].ORDER_KEY evaluates 
> to 10, [Time].[2009].[July].ORDER_KEY evaluates to 7.
>
> (Aside. And as we know ORDINAL is somewhat broken. If there is no 
> integer ordinal column that numbers every member in every level of a 
> hierarchy, mondrian should construct a compound value that implements 
> java.lang.Comparable and has a sensible toString() and that should get 
> used. But that's a separate topic.)
>
> (Sorry I didn't chime in earlier. I have been even busier than usual, 
> and have not been getting through my email backlog - especially those 
> that contain links to long design discussions.)
>
> In the 'cons' of OrderSet you do not mention that it is against the 
> spirit of MDX to let members evaluate to members, and this is a big one.
>
> A sign of this is in the code - you check whether a member is a 
> measure in order to figure out how to evaluate it. Elsewhere in 
> mondrian (and the MDX language) measures are treated like regular members.
>
> I do not think that this will not necessarily change the underlying 
> implementation. You could recognize usages of the ORDER_KEY property 
> and convert it into a sort key with isMemberValueExp=true. My hunch is 
> that regarding everything as an expression will simplify the 
> implementation, but I will leave that to you.
>
> Julian
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>