[Mondrian] Antwort: RE: Custom MemberReader?

Andreas_Voss at tonbeller.com Andreas_Voss at tonbeller.com
Wed Apr 8 07:50:17 EDT 2009


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
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/319fbee1/attachment.html 


More information about the Mondrian mailing list