[Mondrian] Names vs. Unique Names

[Julian Hyde]

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
as case-sensititivity.
 
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].[94705], 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.
 
Julian


  _____  

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...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20080126/9e821d87/attachment.html