<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    Regarding omitted dimension keys, it seems incorrect to require the
    key for degenerate dimensions.&nbsp; I also notice the example of
    degenerate dimensions in Mondrian in Action leaves off the key, so
    it may be good to leave it optional.<br>
    <br>
    I was considering adding a check in RolapSchemaLoader to verify that
    in cases where the key is missing that the attribute list is size 1,
    since that should only happen with a degenerate dim.&nbsp; We could then
    automatically assign the key to be that one attribute.&nbsp; Does that
    seem reasonable?<br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 11/04/2013 12:15 PM, Matt Campbell
      wrote:<br>
    </div>
    <blockquote cite="mid:60DAC7BD8D63084E8252254DF3F110200B7A96494A@MBX36.exg5.exghost.com" type="cite">
      
      Thanks for the feedback.&nbsp; I've run into one more issue.&nbsp; When
      applying a context constraint
      (SqlConstraintUtils.addContextConstraint) we construct a cell
      request based on the non all members in the evaluator, and we use
      that cell request when getting the list of columns to include in
      the constraint.&nbsp; Problem is, if the evaluator contains [Store
      Sales] in a query that spans both the Sales measure group and
      Warehouse measure group, the context constraint we construct can
      bring in the wrong fact table, since we're now using the PhysPath
      to find the parent table.&nbsp; So we now have cases where UNION'd
      tuple queries will include both sales_fact_1997 and
      inventory_fact_1997 in a single FROM.&nbsp; This happens with
      VirtualCubeTest.testNonEmptyCJConstraintOnVirtualCube, for
      example.<br>
      <br>
      I'm thinking that logic needs to now look at the fact table that's
      specified in the SqlQueryBuilder and use that when constructing
      the list of constrained columns.<br>
      <br>
      <br>
      <div class="moz-cite-prefix">On 11/01/2013 07:41 PM, Julian Hyde
        wrote:<br>
      </div>
      <blockquote cite="mid:755F4727-7B8E-463E-B2AA-368A0A255B21@pentaho.com" type="cite">
        On Nov 1, 2013, at 1:22 PM, Matt Campbell &lt;<a moz-do-not-send="true" href="mailto:mcampbell@pentaho.com">mcampbell@pentaho.com</a>&gt;
        wrote:<br>
        <div><br class="Apple-interchange-newline">
          <blockquote type="cite">
            <div bgcolor="#FFFFFF" text="#000000">Hi Julian,<br>
              I've been working on merging in the queryBuilder branch
              and could use some guidance on some test failures I'm
              seeing.<br>
              <br>
              1)&nbsp; There are two failures involving missing dimension
              keys.&nbsp; From the comment in
              SchemaTest.testKeyAttributeMissing(), it sounds like
              dimensions with omitted keys are permitted, so long as
              they don't link to a measure group.&nbsp; While resolving names
              during schema load, the code attempts to find a path to
              all dimensions.&nbsp; This throws an exception in cases where
              there
              <i>is</i> no path.&nbsp; Do you have any suggestions for
              handling this case?&nbsp; It's also not clear to me why we
              allow the key to be left off.<br>
            </div>
          </blockquote>
          <div><br>
          </div>
          I don't recall why I allowed a dimension's key attribute to be
          omitted.</div>
        <div><br>
        </div>
        <div>I don't think there would be a problem if we made it
          required.</div>
        <div><br>
          <blockquote type="cite">
            <div bgcolor="#FFFFFF" text="#000000">2)&nbsp; Closure tables can
              cause an infinite loop.&nbsp; For example, in
              ParentChildHierarchyTest.testClosureTableInVirtualCube().&nbsp;
              Stepping through this logic, it looks like we're trying to
              find the parent table of salary.&nbsp; We find the path from
              employee_closure to salary, but end up looping back around
              to find the parent table of salary again.<br>
            </div>
          </blockquote>
          <div><br>
          </div>
          That sounds plausible. In that query are two usages of salary.
          They are different usages because they join to the fact table
          on different primary key/foreign key combinations. The logic
          that finds &quot;tables&quot; should recognize that.</div>
        <div><br>
        </div>
        <div>Suggest that you disable the test and log a jira case.</div>
        <div><br>
        </div>
        <div>The problem might also occur if there are two uses of a
          dimension table by regular dimensions via different foreign
          keys.</div>
        <div><br>
          <blockquote type="cite">
            <div bgcolor="#FFFFFF" text="#000000">I think the other test
              differences I'm seeing are not real errors.&nbsp; There is a
              difference in the members of the product dimension, for
              example, due to the fact that queries which load members
              of snowflake dimensions now join the tables together.
              There are some product_category values that drop out when
              you join product to product_class (like [Dry Goods]). &nbsp;</div>
          </blockquote>
          <div><br>
          </div>
          At some point I made that &quot;snowflake referential integrity&quot;
          behavior a preference. I slightly favor the old behavior (no
          join, which means more efficient queries, even though members
          may later disappear when you join in higher levels) but I can
          live with the change.</div>
        <div><br>
          <blockquote type="cite">
            <div bgcolor="#FFFFFF" text="#000000">Also, there are many
              differences in SQL results due to different ordering of
              tables in the FROM.<br>
            </div>
          </blockquote>
          <div><br>
          </div>
          That's expected. Now might be a good time to (a) obsolete
          reference queries from databases other than MySQL (unless they
          are testing database-specific features), (b) regenerate
          reference queries with line-feeds (long lines are difficult to
          diff).</div>
        <div><br>
        </div>
        <div>Julian</div>
        <div><br>
        </div>
        <div>PS I took the liberty of replying to the public list.</div>
        <div><br>
        </div>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>