Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <20914677.1180480095882.JavaMail.jira@brutus>
Date: Tue, 29 May 2007 16:08:15 -0700 (PDT)
From: "A B (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-2526) Wrong query results due to column
 ordering in UNION view
In-Reply-To: <17995563.1175729012257.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

A B updated DERBY-2526:
-----------------------

    Attachment: d2526_v2.stat
                d2526_v2.patch

Thank you for reading the write-up and verifying the fix, Bryan.  I'm attaching a second version of the patch, d2526_v2.patch, which adds some relevant test cases to the lang/joins.sql test.  That test is already run as part of JUnit via the lang.LangScripts class, so no additional JUnit work is required (I don't think).

I re-ran derbyall and suites.All on SUSE Linux with ibm142 as a sanity check, and everything passed.  I also verified that if the engine change is backed out, lang/joins.sql will now fail due to incorrect results.

Thanks again to Bryan for his extensive analysis of the problem.  The _v2 patch is, I think, ready for commit.

> Wrong query results due to column ordering in UNION view
> --------------------------------------------------------
>
>                 Key: DERBY-2526
>                 URL: https://issues.apache.org/jira/browse/DERBY-2526
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.0.2.1, 10.1.3.1, 10.2.2.0, 10.3.0.0
>            Reporter: Bryan Pendleton
>            Assignee: A B
>         Attachments: badQuery.log, d2526_v1.html, d2526_v1.patch, d2526_v2.patch, d2526_v2.stat, derby-2526.sql, DistinctTestNotes.txt, firstTryPatch.diff, goodQuery.log
>
>
> I think both select statements in the attached repro script should return 1 row, but in fact the first statement returns 1 row and the second returns zero rows.
> The only difference between the two statements is that the columns in the UNION view are listed in a different order (bvw vs. bvw2).
> This seems like a bug to me; the order of the columns in the view definition shouldn't matter, should it? 
> As Army noted on the derby-dev list, the fact that this reproduces with 10.0 means that it is not caused by some of the 10.2 optimizer changes. Something else is going wrong.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.