db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1633) Regression: The fields of views are not being calculated properly since
Date Thu, 17 Aug 2006 23:40:14 GMT
    [ 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()

        /* 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

> Regression: The fields of views are not being calculated properly since
> --------------------------------------------------------------------------------
>                 Key: DERBY-1633
>                 URL: http://issues.apache.org/jira/browse/DERBY-1633
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions:,
>         Environment: 2.8 GHZ dual PIV on Windows XP SP2, 2 GB memory
>            Reporter: Prasenjit Sarkar
>         Assigned To: A B
>             Fix For:
>         Attachments: d1633_repro.sql, d1633_v1_reviewOnly.patch, d1633_v2.patch, DERBY-1633_v1.html,
> Database can be assumed to be same as in Derby - 1205 Jira issue
> This works fine in 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.
> 		FROM  
> 			 T_RES_ZONE ZONE left outer join T_VIEW_PORT2ZONE PORT2ZONE on  
> 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


View raw message