[Mondrian] Problem with aggregate tables..

Ati Rosselet ati.rosselet at gmail.com
Mon Oct 22 17:41:13 EDT 2007


Julian.. or whoever can help on this.. ..

Ok.... I've attempted the following modifications, and things seem to be
working - aggregate tables are being used by all linked
dimensions/hierarchies rather than just the first one.  As follows:

RolapStar.java :1784 + (added)

       /**
         * Finds ALL the child tables of the fact table with the given
columnName
         * used in their left join condition. This is used by the
AggTableManager
         * while characterizing the fact table columns. (previous only
returned FIRST child)
         */
       public ArrayList<RolapStar.Table> findTablesWithLeftJoinCondition(
            final String columnName)
        {
            java.util.ArrayList<RolapStar.Table> tables = new
java.util.ArrayList<RolapStar.Table>();
            for (Table child : getChildren()) {
                Condition condition = child.joinCondition;
                if (condition != null) {
                    if (condition.left instanceof MondrianDef.Column) {
                        MondrianDef.Column mcolumn =
                            (MondrianDef.Column) condition.left;
                        if (mcolumn.name.equals(columnName)) {
                            tables.add(child);
                        }
                    }
                }

and AggTableManager.java: 482 - change
                RolapStar.Table rTable =
                    star.getFactTable
().findTableWithLeftJoinCondition(cname);
                if (rTable != null) {
                        JdbcSchema.Table.Column.Usage usage =
                            factColumn.newUsage(
JdbcSchema.UsageType.FOREIGN_KEY);
                        usage.setSymbolicName("FOREIGN_KEY");
                        usage.rTable = rTable;
                 }
to

                ArrayList<RolapStar.Table> rTables =
                        star.getFactTable
().findTablesWithLeftJoinCondition(cname);
                if (rTables != null) {
                    for (RolapStar.Table rTable : rTables){
                        JdbcSchema.Table.Column.Usage usage =
                            factColumn.newUsage(
JdbcSchema.UsageType.FOREIGN_KEY);
                        usage.setSymbolicName("FOREIGN_KEY");
                        usage.rTable = rTable;
                    }
                }

            }
            return (tables.size()==0?null:tables);
        }

So... my question is.. did I break anything.. or caused some instability?
:)  If not... can any core developers take a lok and see if this is
reasonable, or if it goes against some basic principle? I checked the
resulting RolapStar (with toString()) and it seems okay to me...

Cheers
Ati

oh.. and I was wrong.. findTableWithLeftCondition  is NOT identical
(different parameters), and is referenced from the validate method of
ExplicitRules.java..

On 10/22/07, Ati Rosselet <ati.rosselet at gmail.com> wrote:
>
> From delving into the Mondrian code, it appears to have something to do
> with the following:
>
> findTableWithLeftJoinCondition in RolapStar.java (called from
> AggTableManager.java:483)  ..there is also a findTableWithLeftCondition
> which seems to be identical.. and unused.. btw.. anyhow.. if there is a
> column in the Star (here pillangoperiodid) that maps to more than one
> dimension/hierarchy.. this function returns only the FIRST match...(creating
> only one usage entry) leaving all other matching dimensions/hierarchies out
> in the cold.   I assume there is more to this.. and will keep digging...
> I'm guessing it may be a combination of this with the subsequent agg
> matching (maybe again only checking for first somewhere?)
>
> Cheers
> Ati
>
>
> On 10/18/07, Julian Hyde <julianhyde at speakeasy.net> wrote:
> >
> >  Can you clarify? Period and Period2 are based on the same dimension
> > table, with the same primary key, and the same foreign key from the fact
> > table?
> >
> > At this point, it sounds like a bug in the aggregate table recognizer
> > algorithm. There may be a bug logged already. If you can convert into
> > a testcase on the foodmart schema that would help.
> >
> > Julian
> >
> >  <http://lists.pentaho.org/mailman/listinfo/mondrian>
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20071022/575215e7/attachment.html 


More information about the Mondrian mailing list