[Mondrian] Modify SqlTupleReader.readTuples() to use aggregrate tables

Daniel Murray dtmurray3 at gmail.com
Thu Apr 17 16:45:27 EDT 2008


Sorry for bothering... I seem to be having a problem that may have to with
the subject matter. Cooul you please take a look at thread
http://forums.pentaho.org/showthread.php?t=61144 and confirm if my
understandig is correct ?}

If the levels are part of of the Agg, why does the SqlTupleReader have to go
to the dimension table... in my posted case, that makes the agg table
worthless -performance wise...

Please forgive my "newbie" question...

Many thanks, DMurray3

2008/4/2, Will Gorman <wgorman at pentaho.com>:
>
> I've updated this patch provided by Robin to the latest 3.0.2 code, and
> I've attached the changed files to the sourceforge case:
>
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1579663&group_id=35302&atid=414616
>
> There are two outstanding issues that I think should be resolved before
> we commit these changes:
>
> * In both SqlMemberSource and SqlTupleReader, when levels are part of
> the agg table, the code doesn't join on the dimension table to get at
> the caption column, properties, etc.  There should be additional  join
> logic that joins the agg table to the dimension tables to extract this
> info
>
> * Within SqlConstraintUtils.constrainLevel and
> SqlConstraintUtils.constrainMultiLevelMembers we assume that any levels
> that appear in the aggregate table don't specify a separate name column
> field.  Again, this should be fixed by doing some additional join logic
> that joins the agg table to the dimension table.
>
> Thanks Robin for the initial work on this!  I apologize that it's taken
> so long to get back to you.
>
> Will
>
>
> On Wed, 2007-11-14 at 12:08 -0600, Robin Tharappel wrote:
> > Hello,
> >
> > Attached are some changes (based on 2.4.2) which allow Mondrian to use
> > the aggregate tables when obtain members through
> > SqlTupleReader.readTuples(). This change is more substantial than the
> > change required to get SqlMemberSource.getMemberChildern() to use
> > aggregate tables. This is primarily because
> > SqlTupleReader.readTuples() can return members for different
> > dimensions at more than one level. In addition it requires support for
> > native filter constraint (RolapNativeFilter) and top count order by
> > (RolapNativeTopCount).
> >
> > The change primarily involves modifying the constraint classes
> > (MemberChildrenConstraint, TupleConstraint, etc) to take in AggStar
> > and Evaluator to generate the conditions for the constraints using
> > aggregate tables. The process of identifying the aggregate table
> > needed to take into account the dimensions levels that need to be
> > requested in addition to the level at which any of the constraints are
> > specified.
> >
> > Unfortunately this does not handle virtual cubes (it will still hit
> > the fact table to obtain the dimension member even though aggregate
> > tables exists for each of the cubes in the virtual cube). Also there
> > maybe an issue with regarding captions. If an aggregate table with
> > levels is used it may not have the caption columns specified. There
> > was some discussion about this issue in the past (below is the feature
> > request from sourceforge).
> >
> >
> http://sourceforge.net/tracker/index.php?func=detail&aid=1579663&group_id=35302&atid=414616
> >
> > The unit test provided a good way of verifying these changes (as they
> > caught several of my mistakes:)). I was hoping to get some feedback
> > regarding these changes. Let me know if you have any questions or
> > comments.
> >
> > Thanks,
> >
> > Robin
> > _______________________________________________
> > Mondrian mailing list
> > Mondrian at pentaho.org
> > http://lists.pentaho.org/mailman/listinfo/mondrian
>
>
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20080417/39585250/attachment.html 


More information about the Mondrian mailing list