[Mondrian] Names vs. Unique Names
jhyde at pentaho.org
Sat Jan 26 14:50:07 EST 2008
That makes two of us! I tried 'assertExprReturns("M", "[Gender].[All
Gender].[M]")' and was very surprised when it worked. I don't remember that
logic being added to the member-resolution code.
Adding a property sounds like a good idea. Add the tests to
CompatibilityTest, since that already deals with name-resolution issues such
Please indicate in the name and description of the property that it governs
whether the dimension name is required. In future I would like to allow
non-fully-qualified member names, such as [Store].[USA]., if the name
of the last level is globally unique, and I want it to be clear that your
property does not govern that feature.
From: mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org] On
Behalf Of Matt Campbell
Sent: Friday, January 25, 2008 12:15 PM
To: Mondrian developer mailing list
Subject: [Mondrian] Names vs. Unique Names
Despite 6 years of MDX experience, I only recently discovered that you could
refer to a dimension member without specifying the dimension it is a part
of. For example, [M] can be used as a shortcut for [Gender].[All
Gender].[M]. This works in both Analysis Services and Mondrian.
I don't like this feature for a couple reasons:
1) [M] could also mean [Marital Status].[All Marital Status].[M]. There's
no obvious way of knowing which member you'll get.
2) More importantly for us, to figure out which dimension has a member with
that name Mondrian needs to query each and every dimension table in that
cube looking for a match. Since we have 700+ dimensions that essentially
means that the server is brought to a standstill searching for a member that
may or may not exist.
I'd like to add a property (false by default) that will require dimension
name to be included in an identifier. The code change looks trivial. What
do people think?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mondrian