[Mondrian] PC hierarchy and visibility of MemberReader and MemberSource

[Julian Hyde]

MemberReader and MemberSource are internals. Modify them at your own risk.

A parent-child hierarchy based on a table with a <SQL> sub-element looks dubious. The <SQL> element hasn't been tested exhaustively. I wouldn't be surprised if Mondrian ignores it in parent-child hierarchies. If it works for you, fine.

Your issue seems to be how members of parent-child hierarchies are ordered within their parent. Have you tried using the ordinalColumn attribute of Level?

FYI, I changed some stuff in Mondrian 4 (lagunitas branch) about ordering of parent-child hierarchies. I think I decided that the default ordering should be by name, not by id. But you can override by setting the Attribute's orderByColumn or providing a nested OrderBy element. (Note that these XML elements only exist in Mondrian 4.)

Julian


On Nov 27, 2012, at 6:43 AM, damien hostin <damien.hostin at axege.com> wrote:

> Hello,
> 
> 
> XML for the dimension looks like:
> 
>     <Dimension name="Structure">
>     <Hierarchy hasAll="false" name="Structure" caption="Structure" 
> primaryKey="rfoade_i_rfodstide" primaryKeyTable="adedst" 
> defaultMember="STRC" nullParentValue="AXS_ROOT">
>         <Table name="adedst">
>             <SQL dialect="generic">rfoade___rforefide = 'REF' and
>                 rfoade___rfovdeide='VDE' and
>                 rfoadervs=1 </SQL>
>         </Table>
>         <Level name="STRC" table="adedst" column="rfoade_i_rfodstide" 
> parentColumn="rfoade_s_rfodstide" uniqueMembers="true">
>         </Level>
>     </Hierarchy>
>     </Dimension>
> 
> 
> And the MDX :
> 
> select NON EMPTY [DefaultMeasures] ON COLUMNS, NON EMPTY 
> [DefaultDimensions] ON ROWS
> from [cana_cube_1354026362876]
> where [DefaultFilters]
> 
> And the namedset in the schema for the MDX :
> 
>           <NamedSet name="DefaultMeasures">
>             <Formula>{[Measures].[Montant]}</Formula>
>           </NamedSet>
> 
>           <NamedSet name="DefaultDimensions">
>             <Formula>Crossjoin({[Temps.Temps par mois].[2009]), 
> ([Temps.Temps par mois].[2010]}, {([Structure].DefaultMember, 
> [Natures].DefaultMember)})</Formula>
>           </NamedSet>
> 
>           <NamedSet name="DefaultFilters">
>             <Formula>{([Stade].DefaultMember, 
> [Processus].DefaultMember, [rfovsn].DefaultMember)}</Formula>
>           </NamedSet>
> 
> 
> Closure table are not mandatory, but I think we can't skip them if we 
> want good performances with parent-child hierarchies. I though it would 
> be easier to debug without.
> 
> I can give more information, but I'm not sure what could help.
> 
> 
> Thanks,
> 
> Damien
> 
> Le 27/11/2012 14:54, Kurtis Walker a écrit :
>> Damien,
>>   Can you send an example of the MDX you are trying to run and the XML for the dimension in your schema?
>> 
>> Kurt
>> 
>> On Tuesday, November 27, 2012 05:15:12 AM damien hostin wrote:
>>> Hello,
>>> 
>>> I am trying to use parent-child hierarchy, but it has some restriction.
>>> 
>>> It looks like we need to give a list sorted in such a way that parent
>>> always come before their child, even if we are not using Closure Tables.
>>> But in the same time, an order by clause is generated on the parent and
>>> the child column.
>>> 
>>> In foodmart.xml it is OK because parent and child are integer, and
>>> sorted correctly. It is also OK because the hierarchy is always the
>>> same, there is no real-life end user that modify it.
>>> 
>>> In my case, sorting the hierarchy on parent and child doesn't garanted
>>> to give mondrian the correct order. This can't work but it is possible
>>> to change the code. I could have patch mondrian to handle PC hierarchies
>>> with my "custom" order by clause, but regression tests find 35 failures
>>> and 1 error with original code running with derby.
>>> 
>>> As it is possible the give MemberReader or MemberSource own
>>> implementation I decided to use that cleaner way. But
>>> mondrian.rolap.MemberSource uses a MemberCache class that is not visible
>>> outside mondrian's package, and mondrian.rolap.MemberReader is package
>>> visible too. So I must implements my custom MemberReader/Source inside
>>> mondrian project, with my 36 regression.
>>> 
>>> Is it a volunteer restriction or can the visibility be change to allow
>>> outside implementation ? I'm a bit messy with those problems.
>>> 
>>> 
>>> Thanks,
>>> 
>>> Damien Hostin
>>> _______________________________________________
>>> 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