[Mondrian] PC hierarchy and visibility of MemberReader and MemberSource

damien hostin damien.hostin at axege.com
Tue Nov 27 09:43:26 EST 2012


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>
         <Level name="STRC" table="adedst" column="rfoade_i_rfodstide" 
parentColumn="rfoade_s_rfodstide" uniqueMembers="true">

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">

           <NamedSet name="DefaultDimensions">
             <Formula>Crossjoin({[Temps.Temps par mois].[2009]), 
([Temps.Temps par mois].[2010]}, {([Structure].DefaultMember, 

           <NamedSet name="DefaultFilters">
[Processus].DefaultMember, [rfovsn].DefaultMember)}</Formula>

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.



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

More information about the Mondrian mailing list