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

[Will Gorman]

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