Change 11956 checked in for Order() function [was: Re: [Mondrian] Re: Eigenbase perforce change 11758 for review]

Khanh Vu kvu at lucidera.com
Tue Nov 18 19:41:47 EST 2008


Hi all,

I have checked in eigenbase change 11956 to add OrderKey and modify the 
extended syntax of Order function following Julian's suggestions below. 
I have also cleaned up the design doc at 
http://pub.eigenbase.org/wiki/MondrianOrderFunctionExtension to reflect 
the final shape of the function. Please let me know if you have any 
concerns.

Thanks,

Khanh.



Khanh Vu wrote:
> 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