<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Nov 1, 2013, at 1:22 PM, Matt Campbell <<a href="mailto:mcampbell@pentaho.com">mcampbell@pentaho.com</a>> wrote:<br><div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<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) There are two failures involving missing dimension keys. 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. While resolving names during schema load,
the code attempts to find a path to all dimensions. This throws an
exception in cases where there <i>is</i> no path. Do you have any
suggestions for handling this case? 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) Closure tables can cause an infinite loop. For example, in
ParentChildHierarchyTest.testClosureTableInVirtualCube(). Stepping
through this logic, it looks like we're trying to find the parent
table of salary. 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 "tables" 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.
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]). </div></blockquote><div><br></div>At some point I made that "snowflake referential integrity" 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>
</body></html>