[Mondrian] Non collapsed AggLevel support in Mondrian

Luc Boudreau lucboudreau at gmail.com
Mon Oct 31 20:02:20 EDT 2011


Nick,

Thanks for the review. You are right. It was previously assumed that
the keys needed to be unique, but as you pointed out, we already have
means of validating it is the case. I've fixed the code and added unit
tests to enforce this.

Cheers!

Luc

On Mon, Oct 31, 2011 at 7:34 PM, Nicholas Goodman
<ngoodman at bayontechnologies.com> wrote:
>
> On Oct 30, 2011, at 5:14 PM, Luc Boudreau wrote:
>
>> aggregation table. At runtime, Mondrian will figure out the parent
>> tables to join to and make sure that all the upper levels are included
>> as well. In a scenario where the dimension is a web of snowflake
>> dimension tables, this has the advantage of making the "brn" column
>> re-usable for each dimension or hierarchy which uses it. Better yet,
>> this also works with the automatic aggregate table recognizer.
>
> Does this new feature require that the level that is the target of the "collapsed" AggLevel be a level with uniqueMembers="true" and is this enforced (or at least checked)?  ie, without this restriction I'm not sure how you'd be able to use the table to build accurate results.
>
> - year
> -- qtr
> 2007/Q1
> 2007/Q2
> 2007/Q3
> 2007/Q4
> 2008/Q1
> 2008/Q2
> 2008/Q3
> 2008/Q4
>
> In the above case the qtr level (column) isn't unique and so if included in the aggregate table by itself, without the parent keys, it wouldn't actually allow the agg table to be used to generate accurate results.  I simply can't think of any way to generate SQL that would build accurate results unless omitting the parent keys unless uniqueMembers = "true" for that level.
>
> Nick
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>


More information about the Mondrian mailing list