[Mondrian] Issues with Calculated Members...

[Will Gorman]

I've started working on bug #1801069, issues with calculated members:

http://sourceforge.net/tracker/index.php?func=detail&aid=1801069&group_id=35302&atid=414613

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
they reside.

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!

Will