[Mondrian] Re: Eigenbase perforce change 11758 for review

Julian Hyde jhyde at pentaho.com
Tue Oct 28 09:50:52 EDT 2008



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20081028/1c80d3c0/attachment.html 


More information about the Mondrian mailing list