hi Julian,<div>I think my explanation of the problem was a bit misleading.</div><div><br></div><div>The actual problem is that there are N objects on a level with the same unique name.</div><div>In the case I quote below one has ordinal 10 and the other has ordinal 11.</div>

<div><br></div><div>Because I use the unique name as primary for my proprietary metadata serialisation I only get the first one, the one with ordinal 10.</div><div>I can reproduce it reliably.</div><div><br></div><div>Shall I file a JIRA for this one too?</div>

<div><br></div><div>thanks,</div><div>Michele</div><div><br></div><div><br><div class="gmail_quote">On 7 April 2011 00:15, Julian Hyde <span dir="ltr">&lt;<a href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">



<div>
<div><span><font color="#000080" size="2" face="Lucida Sans"><span><font color="#000080" size="2" face="Lucida Sans">The olap4j specification doesn&#39;t require that a driver always 
gives out the same java object for a given OLAP object. If you want to check 
whether two objects are &#39;the same&#39;, use the .equals() method. (Or use 
.getUniqueName().equals() if you prefer.)</font></span></font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"><span></span></font></span> </div>
<div><span><font color="#000080" size="2" face="Lucida Sans"><span></span>I believe that the 
driver generates wrapper objects. If you access the same member at different 
times, you might get a different object every time. </font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"></font></span> </div>
<div><span><font color="#000080" size="2" face="Lucida Sans">(Don&#39;t worry about performance. Given how efficient java gc 
is these days, I reckon that it is cheaper to create a new wrapper each time 
than to maintain a hashtable to ensure that we always give out the same object 
every time. The table would have to be thread-safe, would require at least 4 
pointers per Map.Entry, et cetera. When writing the driver, we made sure that 
wrapper objects are immutable, very cheap to construct and contain very little 
data.)</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"></font></span> </div>
<div><span></span><font face="Lucida Sans"><font color="#000080"><font size="2">Julian</font></font></font></div>
<div><font face="Lucida Sans"><font color="#000080"><font size="2"><span></span></font></font></font><br> </div>
<blockquote style="border-left:#000080 2px solid;padding-left:5px;margin-left:5px;margin-right:0px" dir="ltr">
  <div dir="ltr" lang="en-us" align="left">
  <hr>
  <font size="2" face="Tahoma"><b>From:</b> <a href="mailto:mondrian-bounces@pentaho.org" target="_blank">mondrian-bounces@pentaho.org</a> 
  [mailto:<a href="mailto:mondrian-bounces@pentaho.org" target="_blank">mondrian-bounces@pentaho.org</a>] <b>On Behalf Of </b>Michele 
  Rossi<br><b>Sent:</b> Wednesday, April 06, 2011 5:57 AM<br><b>To:</b> Mondrian 
  developer mailing list<br><b>Subject:</b> [Mondrian] non unique members of 
  foodmart&#39;s [Customers] level<br></font><br></div><div><div></div><div class="h5">
  <div></div>Hi,
  <div>I am using the foodmart database with the latest mondrian to test some of 
  my code and I&#39;ve run into something puzzling.</div>
  <div><br></div>
  <div>It looks like in Cube &quot;Sales Ragged&quot; we find several members of 
  level [Customers].[Name] appearing more than once.</div>
  <div><br></div>
  <div>One of those members has unique name 
  [Customers].[Canada].[BC].[Burnaby].[Cindy]</div>
  <div><br></div>
  <div>What I found is also that the duplicate objects (instances of 
  MondrianOlap4jMember) are distinct java objects but delegate internally to the 
  same mondrian.olap.Member instance.</div>
  <div><br></div>
  <div>Am I going crazy or am I missing something pretty obvious again?</div>
  <div><br></div>
  <div>thanks,</div>
  <div>Michele<br clear="all"><br>-- <br><span style="border-collapse:collapse;font-family:arial, sans-serif;font-size:13px">
  <p style="margin:0px 0px 12pt"><b><span style="color:navy;font-size:8pt"><br></span></b></p>
  <p style="margin:0px 0px 12pt"><b><span style="color:navy;font-size:8pt">Michele Rossi</span></b><span style="color:rgb(31,73,125);font-size:8pt"><br><br></span><span style="color:rgb(31,73,125);font-size:8pt"><img src="cid:929060622@06042011-165E"></span><span style="color:rgb(31,73,125);font-size:8pt"></span></p>


  <p style="margin:0px 0px 12pt"><span style="color:rgb(31,73,125);font-size:8pt">Via San Martino, 52, 56125 Pisa, 
  ITALY<br>T: +39 050 220 3894<br><a style="color:rgb(42,93,176)" href="mailto:m.rossi@iontrading.com" target="_blank"><span style="color:blue">m.rossi@iontrading.com</span></a><br><a style="color:rgb(42,93,176)" href="http://www.iontrading.com/" target="_blank"><span style="color:blue">http://www.iontrading.com</span></a></span></p>

</span><br></div></div></div></blockquote></div>
<br>_______________________________________________<br>
Mondrian mailing list<br>
<a href="mailto:Mondrian@pentaho.org">Mondrian@pentaho.org</a><br>
<a href="http://lists.pentaho.org/mailman/listinfo/mondrian" target="_blank">http://lists.pentaho.org/mailman/listinfo/mondrian</a><br>
<br></blockquote></div><br></div>