[Mondrian] PC hierarchy and visibility of MemberReader and MemberSource

damien hostin damien.hostin at axege.com
Fri Dec 7 09:29:00 EST 2012


Le 04/12/2012 09:47, damien hostin a écrit :
>> Great. Thank you for converting to a repro case. Please log this as a jira case, post the case URL to this list, and I promise I will look at it today. (Not promising to fix it immediately...)
>>
>> Julian
>> _______________________________________________
>> Mondrian mailing list
>> Mondrian at pentaho.org
>> http://lists.pentaho.org/mailman/listinfo/mondrian
> Here is the Jira:
>
> http://jira.pentaho.com/browse/MONDRIAN-1328
>
> I am still looking at this problem since I must get it work. We are
> migrating from an old mondrian 3.1.6-7 (cvs build with few obscure
> patches). If I manage to find a fix, I'll post it.
>
>
> Damien
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian


Sorry if I seem to be rude, but english is not my mother tongue. I just 
wanted to say that I'm investigating this problem even you had no time.

Using a parent child hierarchy with hasAll="false" is a valid need. I 
begun to put a "return column;" in SqlTupleReader.Target.internalAddRow 
just after the logger.warn
that tell the hierarchy is missing the parent element. This allow to 
display the hierarchy correctly but break the following test :
mondrian.olap.fun.NativizeSetFunDefTest.testLeafMembersOfParentChildDimensionAreNativelyEvaluated

So I drop that modification and try something else.
I found that mondrian.olap.Util.lookupHierarchyRootMember(...) doesn't 
only return root elements when called with a hasAll=false hierarchy.

I don't think it is the expected behaviour, I'll post a patch when I'll 
find a fix.

Thx anyway,

Damien Hostin




More information about the Mondrian mailing list