[Mondrian] proposal for Order function with key specification list

Julian Hyde jhyde at pentaho.com
Thu Sep 4 03:01:02 EDT 2008


> I added some examples here, together with the updated syntax:
> http://pub.eigenbase.org/wiki/MondrianOrderFunctionExtension

I disagree with rule #1 in these examples:

> Sort are performed using the keys according to the order they appear.
> Hierarchical order is followed for a level if this is the only level from
> the same hierarchy used in the key specification. For example, for a
report
> displaying both 'Year' and 'Quarter' with 'Quarter' being the most
detailed
> level:
>  1. Sort key [Time].CurrentMember, ASC will sort quarters in yearly order;
>  2. Sort key [Time].CurrentMember, ASC, Ancestor([Time].CurrentMember,
>     [Time].[Year]), ASC will sort quarters the same way as when
>     [Time].CurrentMember, BASC, Ancestor([Time].CurrentMember,
>     [Time].[Year]), ASC is used 

Specifically example 2. To be consistent with the current ORDER function,
ASC should never break the hierarchy.

Which got me wondering whether it should be legal to combine ASC and BASC in
the same ORDER call. I think it should be legal, even though I am hard
pressed to find a case where it would be useful.

Order(<set>, <key1>, <dir1>, <key2>, <dir2>)

should always be equivalent to

Order(
  Order(
    <set>,
    <key2>, <dir2>),
  <key1>, <dir1>)

and similarly generalizing for n > 2.

Does that allow you to achieve your desired sorting effect? I think it does.

Julian





More information about the Mondrian mailing list