[Mondrian] Re: Eigenbase perforce change 11758 for review
rchen at lucidera.com
Tue Oct 28 17:46:19 EDT 2008
We have in fact discussed the exact same comment as yours regarding
CollationKey. The wiki section below is now expanded with some more details:
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.
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
>> An earlier post here asked for inputs for the syntax options considered:
>> (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.
> 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]..[October].ORDER_KEY evaluates
> to 10, [Time]..[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.
> Mondrian mailing list
> Mondrian at pentaho.org
More information about the Mondrian