<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6001.17052" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=327484019-26012008><FONT face=Verdana 
color=#000080 size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=327484019-26012008><FONT face=Verdana 
color=#000080 size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=327484019-26012008><FONT face=Verdana 
color=#000080 size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=327484019-26012008></SPAN><FONT 
face=Verdana><FONT color=#000080><FONT size=2></FONT></FONT></FONT>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=327484019-26012008><FONT face=Verdana 
color=#000080 size=2>Please indicate in the name and description of the property 
that it governs whether the <EM>dimension name </EM>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=327484019-26012008><FONT face=Verdana 
color=#000080 size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><FONT face=Verdana><FONT color=#000080><FONT 
size=2>J<SPAN 
class=327484019-26012008>ulian</SPAN></FONT></FONT></FONT></DIV><BR>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000080 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> mondrian-bounces@pentaho.org 
  [mailto:mondrian-bounces@pentaho.org] <B>On Behalf Of </B>Matt 
  Campbell<BR><B>Sent:</B> Friday, January 25, 2008 12:15 PM<BR><B>To:</B> 
  Mondrian developer mailing list<BR><B>Subject:</B> [Mondrian] Names vs. Unique 
  Names<BR></FONT><BR></DIV>
  <DIV></DIV><BR>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.&nbsp; For example, [M] can be used as a shortcut for 
  [Gender].[All Gender].[M].&nbsp; This works in both Analysis Services and 
  Mondrian.<BR><BR>I don't like this feature for a couple 
  reasons:<BR><BR>1)&nbsp; [M] could also mean [Marital Status].[All Marital 
  Status].[M].&nbsp; There's no obvious way of knowing which member you'll 
  get.<BR>2)&nbsp; 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.&nbsp; 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.<BR><BR>I'd like to add a property (false by 
  default) that will require dimension name to be included in an 
  identifier.&nbsp; The code change looks trivial.&nbsp; What do people 
  think?<BR><BR><BR></BLOCKQUOTE></BODY></HTML>