[Mondrian] Re: Eigenbase perforce change 11758 for review

Julian Hyde jhyde at pentaho.com
Fri Oct 31 19:57:49 EDT 2008

On Fri, 2008-10-31 at 15:50 -0700, Rushan Chen wrote:

> Hi Julian,
> I see your suggestions regarding using a set of values along the 
> hierarchy to compare member hierarchically. It will solve the DESC/ASC 
> issue so that client does not need to enumerate the keys from parent levels.
> However, I think this still does not address the issue of supporting 
> existing member comparison semantics (see FunUtil.compareSiblingMembers()):
> (1) Calculated members collate greater than stored members; 
> non-determined if compared with another calculated member.
> (2) If two members do not have order key value, compare by ordinals and 
> if they are the same, compare by member unique name.
> To support the above for a set of members from a single level dimension, 
> should the ordinal returned be a compound also? The compound will need 
> to include information on : (1) calculated vs non,  (2) order key or 
> ordinal,  (3) member unique name.
> Please let me know if discussing this offline is more efficient.


We're at odds because we're coming at this from two different
directions. I'm trying to establish whether Order(<list expr>, {<sort
expr>, <flag>}...) is capable of expressing any form of sort we need.
And you're trying to establish that it can be implemented efficiently.

Obviously I don't want to saddle us with a specification that is
impossible to implement efficiently - or impossible to implement period.
But also I don't want to make the MDX language more complicated for the
end-user because we are driven by how things are working internally.

I haven't heard any cases that Order can't handle - when combined
with .Order_key and .Ordinal. But you point out some complexities of the
implementation that I hadn't thought of.

I think the implementation details can be worked out. As you point out,
if we explicitly instantiate this compound value, we would need to
include whether it is calculated, the ordinal, and the unique member
name in order to make the logic work. We probably wouldn't instantiate
this compound value explicitly: we would return a Comparable object
which has a 'Comparable getParent()' method which creates the next
object if the previous comparison has yielded 0. Or, we could recognise
patterns like Order(<set>, <dimension>.CurrentMember.Order_Key) and
Order(<set>, <dimension>.CurrentMember.Ordinal) and translate them into
code that never actually calls Ordinal or Order_Key at all - code in
fact very similar to the code you have already written.

Do you think that any of those implementations could be made to work?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20081031/0648e2e5/attachment.html 

More information about the Mondrian mailing list