[ 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
