[Mondrian] RE: Custom MemberReader?

Julian Hyde jhyde at pentaho.com
Wed Apr 8 02:15:18 EDT 2009

Custom member readers never really got off the ground. The problem is that
they both need to drive and to constrain. By drive, I mean that the
dimension knows a list of its own values and can generate values; by
constrain, I mean that constraints on the dimension can constrain queries
involving the dimension, such as (but not limited to) generating constraints
on SQL queries. In short, I never figured out what the API should look like,
and I never got any tests running, so the feature never happened.
Over the next year, I want to move the system in the direction of algebraic
optimization. Concepts such as attributes and constraints have meaning when
they interact with other constructs via rules. Sounds a bit abstract, hope
I'm making sense.
The RolapCubeXyz wrapper classes are intended to simplify sharing of
hierarchies, members, and in particular member caches. The idea is that the
'meat' is in the member, which is sharable, and a RolapCubeMember is just a
pair of pointers associating a member with a particular cube. Problem is, we
haven't finished the job yet. We need to make RolapMember an interface, so
that RolapCubeMember doesn't need to inherit all of RolapMember's data
I agree that it's a bit haphazard how things get wrapped in RolapCubeXyz
objects. I've thought of making things clearer by making sure that RolapXyz
and RolapCubeXyz do NOT implement the same interfaces. In effect, we would
be introducing a layer of abstraction into the architecture. Or perhaps
merging into an existing layer - it's difficult to tell until we actually do
The big thing happening in this code is to introduce phyiscal schemas. This
work is well underway, lots of code changes, and I do not want to have to
merge in other major code changes until it is complete. One of the things
happening is that mondrian will be more attribute-oriented. Hierarchies will
be a loose association of attributes. So, I don't know what that will mean
for member readers.
in short: I would appreciate some help to do all of this refactoring, but I
can't imagine taking on other major changes to the guts of mondrian right


From: Andreas_Voss at tonbeller.com [mailto:Andreas_Voss at tonbeller.com] 
Sent: Tuesday, April 07, 2009 11:56 AM
To: jhyde at pentaho.com; Mondrian developer mailing list
Subject: Custom MemberReader?

Hi all, 

I need to implement (and hopefully contribute) a custom MemberReader that
generates a time dimension using a calendar. The customer wants to see all
dates even if they do not appear in the database. The generated time members
must behave as if they came from the database, for example, if such a
generated member is in the slicer, its key must be part of the SQL
where-clause when the cells (Segments) are loaded. 

So I sat the attribute memberReaderClass of the hierarchy in the schema and
wrote a class that implements MemberSource. But my class was not
instantiated, instead I got a NPE in RolapHierarchy.getUniqueTable() where
the relation member is null. I have not yet found the reason for this. 

When browsing through the code I found another weird thing. The class
RolapCubeSqlMemberSource extends SqlMemberSource and is instantiated
directly from (No)CacheRolapCubeHierarchyMemberReader in RolapCubeHierarchy,
without checking if a custom MemberReader exists. This code seems to be
quite new (not in version 2.2.x). I dont think I understand how/why
everything (RolapMember, RolapHierarchy etc) gets wrapped by a corresponding
RolapCubeXyz version. 

Also probably the native crossjoin code must be examined, if a custom member
reader is involved then the native code can not be used.

Currently I'm quite lost. Is a custom MemberReader the right way to
implement the requirement? Or is it a  relict from long ago that won't work
any more? Are there other glitches in the code that could prevent it from
function? And I dont understand the RolapCubeXyz wrapping - should the
MemberSource wrap its members or are they wrapped later? Lots of questions

An example of a custom MemberReader would be great ;-) 

Thanks for any hints, 

Werner-von-Siemens-Str. 2
D-64625 Bensheim 


Register Court: District Court Darmstadt
Registration: HRB 21474
Managing Board: Rutger Hetzler (CEO), Sebastian Hetzler, Torsten Mayer
Chairman of the Supervisory Board: Rüdiger Brand


This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete the
original. Any unauthorised copying or dissemination of this message is
strictly prohibited.

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die Weitergabe
dieser E-Mail ist nicht gestattet.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20090407/b21e5a76/attachment.html 

More information about the Mondrian mailing list