[Mondrian] queryBuilder merge

[Julian Hyde]

On Nov 1, 2013, at 1:22 PM, Matt Campbell <mcampbell at pentaho.com<mailto:mcampbell at pentaho.com>> wrote:

Hi Julian,
I've been working on merging in the queryBuilder branch and could use some guidance on some test failures I'm seeing.

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 is 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.

I don't recall why I allowed a dimension's key attribute to be omitted.

I don't think there would be a problem if we made it required.

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.

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.

Suggest that you disable the test and log a jira case.

The problem might also occur if there are two uses of a dimension table by regular dimensions via different foreign keys.

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]).

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.

Also, there are many differences in SQL results due to different ordering of tables in the FROM.

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).

Julian

PS I took the liberty of replying to the public list.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20131101/62a14525/attachment.html