<div dir="ltr">In an ideal world, I&#39;d like all members of an attribute to be able to compare to any other attribute in the context of a given hierarchy. That&#39;s the core problem here. <div><br></div><div>What you propose, namely cheating with keys by placing &#39;undetermined&#39; keys at the end won&#39;t help with performance-driven requirements. As you mentioned, the trick is to keep the algorithm simple enough so that a CPU can effectively process the sort operation. To do that inside of the regular Java APIs, we must stick to primitive types, like int or long and such. But lo and behold, there is a disconnect here. In OLAP, a boolean or an integer can be null, thus wrecking havok (with a k because it gets really nasty).</div>

<div><br></div><div>That&#39;s why I say that trivial java APIs won&#39;t be of help. I&#39;ve seen enough ClassCastException to last me a lifetime at this point and I&#39;d rather we get this out of the way for good.</div>

<div><div><br></div><div>I&#39;m also having problems figuring out how to fit parent-child attributes in this. We know that parent-child relations between attributes must be promoted to first class concepts in Mondrian in a somewhat near future. Add to that our discussions about consolidating the cells vs. members representation. With that in mind, the &#39;wider&#39; approach becomes more important for us to keep up with all the goodness coming up. It feels that finding an efficient way to deal with member keys and how they are processed within both the context of the core metadata and an ad-hoc query will be key to all future developments. </div>

</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 18, 2013 at 3:04 PM, Julian Hyde <span dir="ltr">&lt;<a href="mailto:jhyde@pentaho.com" target="_blank">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 class="im">On Sep 18, 2013, at 11:39 AM, Luc Boudreau &lt;<a href="mailto:lucboudreau@gmail.com">lucboudreau@gmail.com</a>&gt; wrote:<br>


<br>
&gt; I don&#39;t think that we&#39;ll resolve this problem with trivial java constructs.<br>
<br>
</div>You might be right. However, non-trivial constructs (e.g. comparators with &#39;if&#39;s or virtual methods) don&#39;t perform as well as trivial constructs because CPUs like things to be simple.<br>
<br>
Suppose that we force calc members to have the same key structure as regular members of that level, and give them a key value so that they collate last (perhaps equal to the last regular member). Could that work?<br>
<span class="HOEnZb"><font color="#888888"><br>
Julian<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br></div>