<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. 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. We could then
automatically assign the key to be that one attribute. 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. I've run into one more issue. 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. 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. So we now have cases where UNION'd
tuple queries will include both sales_fact_1997 and
inventory_fact_1997 in a single FROM. 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 <<a moz-do-not-send="true" href="mailto:mcampbell@pentaho.com">mcampbell@pentaho.com</a>>
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) 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>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>