<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 18, 2013 at 2:24 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">To focus the mind: imagine that a level is based on a boolean column and has two members with keys false and true, plus a calc member.</blockquote>

</div><br>I like your example.</div><div class="gmail_extra"><br></div><div class="gmail_extra">This is a problem we&#39;ve had in the codebase for a long while. We&#39;ve tried to use Java&#39;s sorting APIs by implementing comparators that would resent resorting to &#39;instanceof&#39; checks, but this always somehow turns out out to fail for this reason and that.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Besides, all of Java&#39;s compareTo implementations do hard casting. This is a major problem for us.</div><div class="gmail_extra"><br></div><div class="gmail_extra">

I don&#39;t think that we&#39;ll resolve this problem with trivial java constructs. We&#39;ll need to figure out how to:</div><div class="gmail_extra"><br></div><div class="gmail_extra"> - support asymmetric keys (The key of a calculated member won&#39;t have the same attribute dimensionality as the regular members)</div>

<div class="gmail_extra"> - support hierarchal key comparison (There are two types of sort in OLAP after all)</div><div class="gmail_extra"><br></div><div class="gmail_extra">If we could solve these two issues in one swoop with a neat custom data structure, that would be most awesome.</div>

</div>