[Mondrian] RE: Antwort: RE: Custom MemberReader?

Julian Hyde jhyde at pentaho.com
Wed Apr 8 12:20:32 EDT 2009


That reminds me of another problem with custom member readers: the only
real-world use case I could find was the Time dimension. Does anyone have
another use case for a "user-defined dimension"?
 
Julian


  _____  

From: Andreas_Voss at tonbeller.com [mailto:Andreas_Voss at tonbeller.com] 
Sent: Wednesday, April 08, 2009 4:50 AM
To: jhyde at pentaho.com
Cc: 'Mondrian developer mailing list'
Subject: Antwort: RE: Custom MemberReader?



Thank you - I will generate a time dimension in the database instead. Its
not that flexible but will do. 

Andreas 




"Julian Hyde" <jhyde at pentaho.com> 


08.04.2009 08:15 


Bitte antworten an
<jhyde at pentaho.com>



An
<Andreas_Voss at tonbeller.com>, "'Mondrian developer mailing list'"
<mondrian at pentaho.org> 

Kopie

Thema
RE: Custom MemberReader?

	




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
members. 
  
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
it. 
  
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
now. 
  
Julian 


  _____  

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, 
Andreas 


TONBELLER AG
Werner-von-Siemens-Str. 2
D-64625 Bensheim 
Germany 


 <http://www.tonbeller.com/> www.tonbeller.com 


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. 







TONBELLER AG
Werner-von-Siemens-Str. 2
D-64625 Bensheim 
Germany

www.tonbeller.com 

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/20090408/05977cf0/attachment.html 


More information about the Mondrian mailing list