[Mondrian] Problem with aggregate tables..

Ati Rosselet ati.rosselet at gmail.com
Thu Oct 18 15:37:19 EDT 2007


Or... is there a restriction on having 2 dimensions on the same fact table
with same primary key/foreign key?

specifically we have:

<Dimension name="Period2" foreignKey="pillangoperiodid">
        <Hierarchy hasAll="true" allMemberName="All Periods"
primaryKey="id">
            <Table name="plan_periodgroups_olap_view"/>
            <Level name="Plan Period Group" column="itemgroupid"
nameColumn="itemgroupname" uniqueMembers="true"/>
            <Level name="Period" column="periodname"
ordinalColumn="startdate" uniqueMembers="false"/>
        </Hierarchy>
    </Dimension>

    <Dimension name="Period" foreignKey="pillangoperiodid">
        <Hierarchy hasAll="true" allMemberName="All Periods"
primaryKey="id">
            <Table name="period"/>
            <Level name="Year" column="yearname" uniqueMembers="true"/>
            <Level name="Period" column="name" ordinalColumn="startdate"
uniqueMembers="true"/>
        </Hierarchy>
    </Dimension>

where the "plan_periodgroups_olap_view" table is a view on the "period"
table (and a grouping table) that allows us to create whatever selections of
periods are desired (in a 'group')..   the PK id in both case is the same id
from the "period" table and the FK is the same column in the fact table.

in each case, the AggGen outputs this as one of the aggregate tables:

CREATE TABLE agg_l_XXX_invoice_and_item (
    ledgerid INT8,
    pillangoperiodid INT8,
    amount FLOAT8,
    fact_count INTEGER NOT NULL
);

20:40:50,930 INFO  [STDOUT] insertIntoLost:
INSERT INTO agg_l_XXX_invoice_and_item (
    ledgerid,
    pillangoperiodid,
    amount,
    fact_count)
SELECT
    "invoice_and_item"."ledgerid" AS "ledgerid",
    "invoice_and_item"."pillangoperiodid" AS "pillangoperiodid",
    SUM("INVOICE_AND_ITEM"."AMOUNT") AS "amount",             <--- this caps
seems to be a bug for any case sensitive rdbms.. btw :)
    COUNT(*) AS "fact_count"
FROM
    "invoice_and_item" "invoice_and_item"
GROUP BY
    "invoice_and_item"."ledgerid",
    "invoice_and_item"."pillangoperiodid";


I'll try to do something similar with Foodmart... as long as you can confirm
that we're not doing something that should not be allowed (the MDX runs
fine, data ouput is correct etc.. just the agg tables don't work..)

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
>
>  ------------------------------
> *From:* mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org]
> *On Behalf Of *Ati Rosselet
> *Sent:* Thursday, October 18, 2007 2:58 AM
> *To:* mondrian at pentaho.org
> *Subject:* [Mondrian] Problem with aggregate tables..
>
> Hi, I'll try to be clear here.
> We are running mondrian 2.4 with the Aggregate query generation turned on
> at the moment and we have the following, odd situation:
>
> We have 2 dimensions (Period and Period2), both of which reference the
> same set of id's
> We have also created the appropriate aggregate table for a certain level,
> and all works fine.. kind of.
>
> The problem is that when the query using "Period" runs, the aggregate
> table we created is shown on the console, and the database logs show that it
> used, and consequently everything is FAST!!  However, when using the
> "Period2" dimension, although the EXACT SAME table is shown on the console
> as a suggested aggregate table..  it is never used.
>
> I could understand if it was finding a 'better' table and using that
> instead, but rather it is not using any aggregate table at all.  ??????
>
> What situation could cause the processing of an MDX query to list
> "suggested" tables, and then NOT use one of them if it exists?
> We've been trying, tweaking etc.. and no change..   at a complete loss
> here... any ideas?
>
> Cheers
> Ati
>
>
> (Julian... just found the new mailing list  - thnx... did you shut down
> the old spamful one?)
>
>
> _______________________________________________
> 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/20071018/a103b0f4/attachment.html 


More information about the Mondrian mailing list