[Mondrian] Modify SqlTupleReader.readTuples() to use aggregrate tables
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:
> 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
> * 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.
> 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).
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mondrian