[
http://issues.apache.org/jira/browse/DERBY-1633?page=comments#action_12428832 ]
A B commented on DERBY-1633:
----------------------------
Quick update on where I stand with this issue...
When I was tracing through code for the _v2 patch for this issue, I found two
things that caused me to withdraw the patch from potential commit.
First, there is some special case logic in BinaryRelOpNode.getScopedOperand()
for situations when the scope target ResultColumn could not be found:
+ /* Special case: if the cr has already been "scoped" once and
+ * it corresponds to a ResultColumn whose expression isn't a
+ * ColumnReference (see last line in this method) then rc will
+ * be null here. In that case, we just return a clone of cr.
+ */
+ if (rc == null)
+ return (ValueNode)cr.getClone();
This is the "implicit assumption" that I mentioned in my previous comment, and
when I was tracing through code I realized that this assumption was not
correct. As it turns out, for the queries I was running to get to this code,
the reason rc was null was NOT because it "corresponds to a ResultColumn whose
expression isn't a Column Reference". Rather, it was because the subquery that
the operand-to-be-scoped ("cr") was pointing to had actually been flattened
during preprocessing. To make a long story short, this meant that the
ResultColumn to which "cr" was pointing was redundant and thus was not really
pointing to the correct source result set. This in turn meant that we tried to
find "cr"s (redundant) source result in the childRSN's result column list, we
couldn't find it, and hence rc was null. What we need to do, then, is skip
over the redundant source result set to find the actual result set, and then
search for that in childRSN's RCL.
Having figured out the cause for this special-case logic (namely, subquery
flattening when preprocessing), I have been able to make the appropriate
changes and have thus removed the need for this special-case logic altogether.
So that issue has been resolved.
The second reason I withdrew the patch was for cases where "cr" does actually
correspond to a ResultColumn whose expression isn't a ColumnReference. Namely,
at the very end of the getScopedOperand() method:
/* We can get here if the ResultColumn's expression isn't a
* ColumnReference. For example, the expression would be a
* constant expression if childRSN represented something like:
*
* select 1, 1 from t1
*
* In this case we just return a clone of the column reference
* because it's scoped as far as we can take it.
*/
return (ValueNode)cr.getClone();
As I was tracing through code to figure out the first issue mentioned above, I
noticed that this logic was not updated to reflect the rest of the changes for
the _v2 patch. In particular, the _v2 algorithm for finding the scope target
column involves just retrieving the "whichRC"-th column of childRSN's result
column list if childRSN is the right child of a Union. With the above code, if
the scope target's expression is not a ColumnReference we'll just return a
clone of "cr"--but "cr" will always be w.r.t to the left child, so if childRSN
is actually the right child of a Union, then returning a clone of "cr" is not
the correct thing to do. Instead, we have to return a new ColumnReference
whose source is set to be the whichRC-th result column in childRSN's result
column list.
I have figured out how to implement this second change, as well, and thus have
addressed both of my concerns with the _v2 patch.
However, it is still not clear to me why all of my tests--and derbyall,
too--passed with these errors in the code. So I still need to try to write
more tests to either 1) prove that the _v2 code was wrong (and that my latest
changes are correct) or 2) understand why having apparently incorrect code in
the _v2 patch still makes everything work.
It is this latter task that I'm still investigating. I will post more when I
have more to post...
> Regression: The fields of views are not being calculated properly since
> 10.1.2.4
> --------------------------------------------------------------------------------
>
> Key: DERBY-1633
> URL: http://issues.apache.org/jira/browse/DERBY-1633
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.1.3.0, 10.1.3.1
> Environment: 2.8 GHZ dual PIV on Windows XP SP2, 2 GB memory
> Reporter: Prasenjit Sarkar
> Assigned To: A B
> Fix For: 10.2.0.0
>
> Attachments: d1633_repro.sql, d1633_v1_reviewOnly.patch,
> d1633_v2.patch, DERBY-1633_v1.html, DERBY-1633_v2.html
>
>
> Database can be assumed to be same as in Derby - 1205 Jira issue
> SELECT PORT1.PORT_ID FROM T_RES_PORT PORT1, T_VIEW_ENTITY2PORT ENTITY2PORT
> WHERE ENTITY2PORT.PORT_ID = PORT1.PORT_ID
> This works fine in 10.1.2.1 but fails thereafter complaining that Comparison
> between INTEGER and CHAR is not supported
> for some reason, it thinks one of the PORT_ID columns is a character, when in
> reality both are integers.
> SELECT DISTINCT
> ZONE.ZONE_ID ZONE_ID,
> PORT2ZONE.ZONE_MEMBER_ID
> FROM
> T_RES_ZONE ZONE left outer join T_VIEW_PORT2ZONE
> PORT2ZONE on
> ZONE.ZONE_ID = PORT2ZONE.ZONE_ID , T_RES_FABRIC
> FABRIC
> In this query, it is complaining that one of the columns is a VARCHAR and
> cannot be compared to INTEGER, when clearly this is not the case...
> Same issue
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
