[Mondrian] Order by OrderKey

Matt Campbell mcampbell at pentaho.com
Tue Oct 8 10:33:58 EDT 2013

Regarding non-deterministic ordering of members:  if I'm reading you correctly hierarchical sort order should still be deterministic, correct?  There are some tests which currently fail the assertion in compareHierarchically because two different members result in a compare of 0.  For example testBug1438285() defines ordinalColumn=region_id for [Store Id], which is non-unique under the same parent for some members.

On 10/08/2013 08:59 AM, Julian Hyde wrote:
On Oct 7, 2013, at 7:56 AM, Matt Campbell <mcampbell at pentaho.com<mailto:mcampbell at pentaho.com>> wrote:

I'm looking for a quick sanity check.  Some of the lagunitas test failures involve differences in Order() results.  Ordering by [Customers].currentMember.OrderKey would use the defined orderByColumn (full_name) in lagunitas, but the expected results used customer_id.  I believe that is the correct behavior, and have adjusted the tests for 2 of these failures.  Let me know if I'm off in my assumption.


Looks good.

By the way, I changed the rules by which an order-key is derived if you defined a key and a name column but no order-key. In mondrian-3, it would use the key. But in mondrian-4 it uses the name.

See RolapSchemaLoader.java:

        if (orderByList.isEmpty()) {
            if (nameSpecified) {
                orderByList = Collections.singletonList(nameExpr);
            } else {
                orderByList = keyList;

Does that change of rules make sense? It breaks the month level (where you want to order by key, not name) but I think works in the majority of cases.

I also changed, or at any rate clarified, the semantics of ordering for attributes that have many, many members and are usually used as child levels. Product Name is an example; its key is product_id, and its name and order-key is product_name. The order-key does not need to totally sort the attribute. Since such attributes are usually ordered within their parent, a total order-key would be composite and expensive to evaluate. Such attributes are usually used as a level, and will be sorted within their parent (e.g. product name within product brand within product manufacturer). If such an attribute is used standalone, it doesn't have a deterministic ordering across all members of the attribute. But that doesn't happen often. The effect of this change is to require less sorting in the common case, which is more efficient.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20131008/0015cbd4/attachment.html 

More information about the Mondrian mailing list