<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6001.18203" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=009175305-08042009><FONT face="Lucida Sans" color=#000080 
size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=009175305-08042009><FONT face="Lucida Sans" color=#000080 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=009175305-08042009><FONT face="Lucida Sans" color=#000080 
size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=009175305-08042009><FONT face="Lucida Sans" color=#000080 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=009175305-08042009><FONT face="Lucida Sans" color=#000080 
size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=009175305-08042009><FONT face="Lucida Sans" color=#000080 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=009175305-08042009><FONT face="Lucida Sans" color=#000080 
size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=009175305-08042009><FONT face="Lucida Sans" color=#000080 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=009175305-08042009><FONT face="Lucida Sans" color=#000080 
size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=009175305-08042009><FONT face="Lucida Sans" color=#000080 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=009175305-08042009><FONT face="Lucida Sans" color=#000080 
size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=009175305-08042009><FONT face="Lucida Sans" color=#000080 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=009175305-08042009><FONT face="Lucida Sans" color=#000080 
size=2>Julian</FONT></SPAN></DIV><BR>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000080 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> Andreas_Voss@tonbeller.com 
  [mailto:Andreas_Voss@tonbeller.com] <BR><B>Sent:</B> Tuesday, April 07, 2009 
  11:56 AM<BR><B>To:</B> jhyde@pentaho.com; Mondrian developer mailing 
  list<BR><B>Subject:</B> Custom MemberReader?<BR></FONT><BR></DIV>
  <DIV></DIV><BR><FONT face=sans-serif size=2>Hi all,</FONT> <BR><BR><FONT 
  face=sans-serif size=2>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.</FONT> 
  <BR><BR><FONT face=sans-serif size=2>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.</FONT> <BR><BR><FONT face=sans-serif 
  size=2>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.</FONT> <BR><BR><FONT face=sans-serif size=2>Also probably the native 
  crossjoin code must be examined, if a custom member reader is involved then 
  the native code can not be used.<BR></FONT><BR><FONT face=sans-serif 
  size=2>Currently I'm quite lost. Is a custom MemberReader the right way to 
  implement the requirement? Or is it a &nbsp;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 
  ...</FONT> <BR><BR><FONT face=sans-serif size=2>An example of a custom 
  MemberReader would be great ;-) </FONT><BR><BR><FONT face=sans-serif 
  size=2>Thanks for any hints,</FONT> <BR><FONT face=sans-serif 
  size=2>Andreas</FONT> <BR><BR>
  <DIV style="FONT-SIZE: 10pt; FONT-FAMILY: sans-serif">
  <P><B>TONBELLER AG</B><BR>Werner-von-Siemens-Str. 2<BR>D-64625 Bensheim 
  <BR>Germany</P><A href="http://www.tonbeller.com" 
  target=_blank>www.tonbeller.com</A> 
  <P>Register Court: District Court Darmstadt<BR>Registration: HRB 
  21474<BR>Managing Board: Rutger Hetzler (CEO), Sebastian Hetzler, Torsten 
  Mayer<BR>Chairman of the Supervisory Board: Rüdiger Brand</P>
  <HR style="MARGIN: 20px 0px" noShade SIZE=1>

  <P>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.</P>
  <P>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.</P></DIV><BR></BLOCKQUOTE></BODY></HTML>