[Mondrian] Re: Eigenbase perforce change 11758 for review

Khanh Vu kvu at lucidera.com
Tue Nov 11 14:35:05 EST 2008


Julian,

I have put a proposal for implementing the interface <Member>.OrderKey 
as well as refactoring Order() functions using the OrderKey at
http://pub.eigenbase.org/wiki/MondrianOrderFunctionExtension#Add_.3CMember.3E.OrderKey_.28by_Julian.29

Please review. I have the code ready and would like to check it shortly 
if the proposal looks ok to you.

Thanks,

Khanh.

Rushan wrote:
> Hi Julian,
>
> I agree with you that we should start from a good design and then look 
> at the implementation feasibility.
>
> The proposal documented earlier here 
> <http://pub.eigenbase.org/wiki/MondrianOrderFunctionExtension#Use_a_New_Function_Name_-_OrderSet> 
> is actually the result of verifying a few other suggestions with 
> Mondrian implementation. Probably because of this, the proposal has 
> the appearance of  having originated from implementation.
> A compound sort key returned by the member property(e.g. 
> "[Dim].currentMember.SortKey") can be made to work here. I will take a 
> look and fill in the details in the wiki page.
>
> Rushan
>
> Julian Hyde wrote:
>> 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.
>>>     
>>   
>> Rushan,
>>
>> 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?
>> Julian
>>   
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Mondrian mailing list
>> Mondrian at pentaho.org
>> http://lists.pentaho.org/mailman/listinfo/mondrian
>>   
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>   





More information about the Mondrian mailing list