[Mondrian] proposal for Order function with key specification list

Rushan Chen rchen at lucidera.com
Fri Sep 19 22:49:59 EDT 2008


(Back from vacation and am catching up with the emails...)

Thanks for the many good discussions on this topic in the forum. A few 
response to the suggestions so far:

(1) Regarding using hierarchical sort keys in an order different from 
the hierarchy order, as in the example

Order([Time].members, Ancestor([Time].CurrentMember, [Time].[Year]), 
ASC, Ancestor([Time].CurrentMember, [Time].[Year]), ASC)

Obviously the intention of the user is to sort first on "quarter" and 
then on "year"; so from Julian's suggestions, this should be used instead:

Order([Time].members, Ancestor([Time].CurrentMember, [Time].[Year]), 
BASC, Ancestor([Time].CurrentMember, [Time].[Year]), BASC)

Also, on the topic of whether it is useful to combine BASC/BDESC and 
ASC/DESC, it might be useful for keys from different hierarchies, but 
not much otherwise.

Order(CrossJoin([Time].members, [Product].members), 
Ancestor([Time].CurrentMember, [Time].[Year]), ASC, 
[Product].currentMember, BASC)

(2) Order preservedness of set functions.

For the new Order function, we will declare the order preservedness in 
the document.

For function with native evaluator, conformance in native mode could 
actually make native evaluation not very useful. For example, NECJ of 
two enumerated sets of arbitrary order. For these cases, if the 
application does not provide additional information regarding the 
expected sort order, we could in fact turn off native evaluation.

BTW, Julian, this looks wrong:

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

should always be equivalent to

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

Shouldn't the equivalent expression be this?

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


The eigenpedia doc now contains the latest information:
http://pub.eigenbase.org/wiki/MondrianOrderFunctionExtension

Rushan

Julian Hyde wrote:
>   
>> Currently native NonEmptyCrossJoin and Filter (and maybe 
>> others) are out 
>> of conformance, and native is enabled by default, but 
>> conformance can be 
>> achieved by disabling native.
>>     
>
> I can allow that in the short term. However I would like mondrian to be in
> conformance even in native mode. (I see native mode as an option that
> affects physical behavior, and hence performance, not logical behavior.) To
> use the efficient NonEmptyCrossJoin and Filter, either applications will
> have to put in Unorder, or the compiler will have to get smarter to
> recognize when an enclosing Order means that the underlying function is free
> to return the results in whatever order it wants.
>
> I've just checked in an Unorder function. It does nothing right now, but
> people can use it for optimization.
>
> Julian
>
>
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>   


-- 
Rushan Chen

www.lucidera.com<http://www.lucidera.com/>

Gartner: LucidEra is a business intelligence "Cool Vendor
<http://www.lucidera.com/company/press_releases/cool_Vendor_leading_analyst_firm_9apr.php>

Beagle Research: LucidEra is a CRM WizKid
<http://www.lucidera.com/company/press_releases/lucidera_crm_wizkid_awards_26mar.php>

JMP Securities: LucidEra is in the Hot 100
<http://www.lucidera.com/company/press_releases/jmp_hot_100_best_apr2.php>

-------------------------------------------------------------------------------
This message and any files or text attached to it are intended only for
the recipients named above, and contain information that may be
confidential or privileged. If you are not an intended recipient, or you
have reason to believe that you received this message in error, you must
not read, copy, use or disclose this communication. Please also notify
the sender by replying to this message, and then delete all copies of it
from your system. Thank you.






More information about the Mondrian mailing list