[Mondrian] Closure table with a non-primary key relation

Luc Boudreau lucboudreau at gmail.com
Thu Mar 8 10:28:00 EST 2012


Hi Pat,

Contributions are always welcome, obviously :) Yet for now we are in
the process of wrapping up the 3.4.0 release, and after that, we will
switch all development efforts on the 4.X branch. I think the code
might be quite different in that area (Mondrian 4 introduces a new way
of joining tables and columns).

Julian, do you think that they could develop this feature on the 3.4.0
branch and that it would be portable enough to be worth the effort, or
will his efforts be wasted?

Luc



On Thu, Mar 8, 2012 at 10:23 AM, Patrick Leckey <patl at seewind.com> wrote:
> Hi Mondrian,
>
> In our structure we have a dimension that contains a parent-child hierarchy ("State" - not geographical state, a treatment state) as well as other hierarchies that are contextually related to State.  In our dimension table, State is not a primary key, so when we try to use it with a closure table we end up with an incorrect join generated by Mondrian.
>
> Looking at RolapHierarchy.createClosedPeerDimension(), this is the way Mondrian was designed - it relates the parent column of the closure table to the child column of the unclosed base table, assuming primary keys.
>
> Would Mondrian be open to a patch that allows us to create closure tables where the primary key of the closure's hierarchy doesn't match the child column of the unclosed table?  It would do so by adding a secondary join through the closure table to the base table, and then joining from the closure table to the primary key.  The new patch would only kick in if the closure tables hierarchy primary key doesn't match the closure child column.  If they do match (as is expected now), behaviour would remain unchanged.
>
> Thanks,
> Pat
>
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian


More information about the Mondrian mailing list