[Mondrian] Issues with Calculated Members...
wgorman at pentaho.org
Thu Feb 14 18:34:16 EST 2008
I've started working on bug #1801069, issues with calculated members:
One of the issues is that some calculated members return odd results
when calling [Calc Member].Children. Regularly, calculated members are
defined at the root of a hierarchy such as "[Product].[Test]". Mondrian
creates these members on the first level of the Hierarchy, which is
normally the [(All)] level. As a side effect, when these members are
created, their "isAll()" flag is flipped to true due to the level that
A quick fix to this problem was to not set the all flag for calculated
members. My question is should these calculated members be created at
the [(All)] level in the first place? Also, should calculated members
have the all member if it exists as a parent?
If we were to do that, I'm guessing a lot of test cases would have to
change. The reason is that when you ask for the fully qualified name of
the calculated member, you now would get "[Product].[All
Products].[Test]" vs. just "[Product].[Test]".
The fully qualified name issue is also the reason why defining a
calculated member below the hierarchy level, such as
"[Product].[Food].[Test]" will not work. The Query class attempts to
resolve the calculated name by comparing the string to the
Member.getUniqueName() method, which includes a reference to the all
member. My work around is to also compare the name to a generated
unique name without the all member.
Thanks for any thoughts on both of these items!
More information about the Mondrian