<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix"><br>
      That's the same problem I was trying to explain in this case
      <a class="moz-txt-link-freetext" href="http://jira.pentaho.com/browse/MONDRIAN-1328">http://jira.pentaho.com/browse/MONDRIAN-1328</a> some weeks ago, "an
      ordering problem that come from an unexpected (actually untested)
      hierarchy declaration". I remember that the code seem to load the
      parent-child hierarchy recursively but actually only one SQL
      request is executed with ORDER BY on primary key. I do not
      remember the class name, but something near SqlTupleReader. So if
      this ORDER BY doesn't return the query with parent records before
      children records, there's a lot of warnings. <br>
      <br>
      (By the way, the level is wrong on members of parent-child
      hierarchy even if they are loaded correctly, which doesn't allow
      to build semi-aggregate calculated measure on such hierarchies,
      but that's another history)<br>
      <br>
      I hope it helps.<br>
      <br>
      Damien Hostin<br>
      <br>
      Le 02/04/2013 20:31, Paul Stoellberger a &eacute;crit&nbsp;:<br>
    </div>
    <blockquote
      cite="mid:C9B7DAE0-5F45-4623-95AA-7F14557CE37F@gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      Well I cant really explain it either, but suddenly all the
      warnings that parent values are missing disappeared
      <div><br>
      </div>
      <div>Here the JIRA:&nbsp;<a moz-do-not-send="true"
          href="http://jira.pentaho.com/browse/MONDRIAN-1511">http://jira.pentaho.com/browse/MONDRIAN-1511</a></div>
      <div><br>
      </div>
      <div>I was debugging SqlTupleReader above line 177, and just
        noticed that in the first case the cache was almost empty when
        the first WARNING occured, while the second time it was almost
        full (only 1 warning showed up, which i considered as ok)</div>
      <div>So the order did matter somehow.</div>
      <div><br>
      </div>
      <div><br>
      </div>
      <div><br>
      </div>
      <div>-Paul</div>
      <div><br>
        <div>
          <div>On Apr 2, 2013, at 8:19 PM, Julian Hyde &lt;<a
              moz-do-not-send="true" href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</a>&gt;
            wrote:</div>
          <br class="Apple-interchange-newline">
          <blockquote type="cite">Sounds like good general advice.
            Thanks for letting us know.<br>
            <br>
            Please log a case. I don't see any reason why, say, VARCHAR
            columns couldn't be used as key columns for parent-child
            hierarchies and their closure tables, but I can believe
            there is a bug.<br>
            <br>
            Julian<br>
            <br>
            <br>
            On Apr 2, 2013, at 9:10 AM, Paul Stoellberger &lt;<a
              moz-do-not-send="true"
              href="mailto:p.stoellberger@gmail.com">p.stoellberger@gmail.com</a>&gt;
            wrote:<br>
            <br>
            <blockquote type="cite">Because I just lost almost half a
              day on this:<br>
              <br>
              Can we add a note in the documentation that when using
              parent child hierarchies and closure tables, it is
              mandatory to use numeric keys - otherwise the whole thing
              will just blow up in your face<br>
              <br>
              I ended up getting arbitrary hierarchies because the order
              by clause etc. was actually necessary to compute a correct
              parent child hierarchy. <br>
              And ordering on string values seem to produce a different
              result than ordering numeric values.<br>
              I only changed that and suddenly my PC hierarchies work
              correctly.<br>
              <br>
              And if thats still an issue in mondrian 4 - please add it
              to the book :-)<br>
              <br>
              Thanks<br>
              <br>
              Paul<br>
              <br>
              _______________________________________________<br>
              Mondrian mailing list<br>
              <a moz-do-not-send="true"
                href="mailto:Mondrian@pentaho.org">Mondrian@pentaho.org</a><br>
              <a class="moz-txt-link-freetext" href="http://lists.pentaho.org/mailman/listinfo/mondrian">http://lists.pentaho.org/mailman/listinfo/mondrian</a><br>
            </blockquote>
            <br>
            _______________________________________________<br>
            Mondrian mailing list<br>
            <a moz-do-not-send="true" href="mailto:Mondrian@pentaho.org">Mondrian@pentaho.org</a><br>
            <a class="moz-txt-link-freetext" href="http://lists.pentaho.org/mailman/listinfo/mondrian">http://lists.pentaho.org/mailman/listinfo/mondrian</a><br>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Mondrian mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Mondrian@pentaho.org">Mondrian@pentaho.org</a>
<a class="moz-txt-link-freetext" href="http://lists.pentaho.org/mailman/listinfo/mondrian">http://lists.pentaho.org/mailman/listinfo/mondrian</a>
</pre>
    </blockquote>
  </body>
</html>