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] Updated: (DERBY-1633) Regression: The fields of views are not being calculated properly since 10.1.2.4
Date Mon, 21 Aug 2006 11:03:15 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1633?page=all ]

A B updated DERBY-1633:
-----------------------

    Attachment: d1633_v3_code.patch
                d1633_v3_tests.patch
                DERBY-1633_v3.html

Attaching a third attempt at resolving this issue, d1633_v3_code.patch and d1633_v3_tests.patch.
 I've separated the tests out from the patch because the test diff for lang/predicatePushdown.out
is several thousand lines (that's what happens when code changes affect query plans) and I
didn't want it to interefere with review of the code changes.  I did manually verify all of
the new query plans and while the plans have changed in some ways, they still correctly demonstrate
the behavior that is being tested.

I'm also attaching a _v3 of the HTML file to described the _v3 code changes.  In particular
there is a new section "V" that describes several changes which are in _v3 but were not in
_v2.  Test cases demonstrating the short-comings of _v2 are included in d1633_v3_tests.patch.

I ran derbyall on Red Hat Linux with ibm142 using sane jars against a patch that was very
similar to _v3 and saw no new failures.  I did, however, make some additional changes when
I created _v3 and so need to re-run derbyall again to make sure all is okay.

In the meantime, though, I'm posting the d1633_v3 patches, which I believe to be a complete
solution to the regression described for this issue.  As always, review/comments/commit would
be greatly appreciated.

svn stat:

M      java\engine\org\apache\derby\impl\sql\compile\Predicate.java
M      java\engine\org\apache\derby\impl\sql\compile\SelectNode.java
M      java\engine\org\apache\derby\impl\sql\compile\ProjectRestrictNode.java
M      java\engine\org\apache\derby\impl\sql\compile\BinaryRelationalOperatorNode.java
M      java\engine\org\apache\derby\impl\sql\compile\SetOperatorNode.java
M      java\engine\org\apache\derby\impl\sql\compile\OptimizerImpl.java
M      java\engine\org\apache\derby\impl\sql\compile\ColumnReference.java
M      java\engine\org\apache\derby\impl\sql\compile\ResultColumnList.java
M      java\testing\org\apache\derbyTesting\functionTests\tests\lang\predicatePushdown.sql
M      java\testing\org\apache\derbyTesting\functionTests\master\predicatePushdown.out

> 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.1.0
>
>         Attachments: d1633_repro.sql, d1633_v1_reviewOnly.patch, d1633_v2.patch, d1633_v3_code.patch,
d1633_v3_tests.patch, DERBY-1633_v1.html, DERBY-1633_v2.html, DERBY-1633_v3.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

        

Mime
View raw message