[Mondrian] proposal for Order function with key specification list

Julian Hyde jhyde at pentaho.com
Wed Sep 3 14:38:06 EDT 2008

> Rushan wrote:
> Using member expression is a good idea and in fact works 
> better with the 
> parser. However, member ordinal might not be as reliable as 
> member order 
> key which will be used if CompareSiblingsByOrderKey is set.

I mis-spoke. When I said 'Members ought to collate by ordinal' I meant
'Members ought to collate by their natural order'. Which should work even if
ordinal is not set correctly. So we are in agreement.

> I added some examples here, together with the updated syntax:
> http://pub.eigenbase.org/wiki/MondrianOrderFunctionExtension
> There is also a note on order preservedness (after the MDX 
> examples) of 
> set functions. Currently there is no guarantee from Mondrian, 
> although 
> the implementations can be order preserving. MDX does not 
> have a way to 
> "hint" this property. I would like to know if any other Mondrian 
> applications depend on this property for set functions(Generate and 
> Exists to start with).  If that is the case, then perhaps this can be 
> formalized in documentation.

I don't know whether order-preservation is an explicit design principle of
MDX, but it is definitely pervasive. For example, fundamental set operations
like set-constructor operator "{ ... }", Filter, Crossjoin, Union, Except
all preserve order. In fact, 'set operator' is a misnomer - they work on
lists that have an ordering and may contain duplicates.

So, let's declare that Order function is order-preserving (in
computer-science jargon, it is a stable sort). Given this, your proposed

  order(<set-expr>, <expr1>, asc, <expr2>, asc)

is equivalent to
  order(order(<set-expr>, <expr2>, asc), <expr1>, asc)

But the of course the first form can be implemented more efficiently.


More information about the Mondrian mailing list