[
https://issues.apache.org/jira/browse/DERBY-5010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053503#comment-13053503
]
Kathey Marsden commented on DERBY-5010:
---------------------------------------
Thank you Jayaram for tracking this down!
Can you post the full stack trace from isEquivalent when this statement is
executed?
Now that we know how to get into isEquivalent(), the next step will be to try
to find a variation of this statement that fails without Dave's patch and
passes with it. First, to get yourself setup to debug the situation, I would
suggest you break out an SQL script with just the first part of aggregate.sql
to setup these two tables call it create.sql or some such. Then you can use
that to create a database with ij and then you can just connect with ij to the
database and run this one sql statement and variations to understand what is
happening in isEquivalent, either by printing the values for tableName and
other.tableName or using the debugger.
> [patch] bad equivalence check
> -----------------------------
>
> Key: DERBY-5010
> URL: https://issues.apache.org/jira/browse/DERBY-5010
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.7.1.1
> Reporter: Dave Brosius
> Priority: Trivial
> Fix For: 10.8.1.5
>
> Attachments: IsEquivalent_DoNotCommit_June11.txt,
> IsEquivalent_Donotcommit_june14.txt, bad_equivalence_check.diff, derby.log,
> june15.out, runoutputJune14.out, runoutputJune2.out
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> code attempts to compare two BaseColumnNodes but doesn't compare the
> tableName correctly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
