db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-1861) Column ordering ASSERT when combining column references and expressions in same ORDER BY
Date Sat, 17 Mar 2007 15:44:09 GMT

    [ https://issues.apache.org/jira/browse/DERBY-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481866
] 

Bryan Pendleton commented on DERBY-1861:
----------------------------------------

I still haven't had any more time to look at this. I'm considering committing the patch as
is, because I think it's solid and fixes the identified issue, and filing a follow-on issue
to investigate consolidating (or at least better documenting) the two closely-similar versions
of getOrderByColumn. Having bumped into that confusing bit of code twice now (in DERBY-147
and in this issue) I'd like to follow it up and improve it, but I'd also like to get this
patch committed before it "spoils". If nobody objects, I'll proceed with this plan in the
next week or so.


> Column ordering ASSERT when combining column references and expressions in same ORDER
BY
> ----------------------------------------------------------------------------------------
>
>                 Key: DERBY-1861
>                 URL: https://issues.apache.org/jira/browse/DERBY-1861
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.3.0.0
>            Reporter: Bryan Pendleton
>         Assigned To: Bryan Pendleton
>            Priority: Minor
>         Attachments: adjustOffsets_v1.diff, dataStructureNotes.html, proposedPatchNotes.html
>
>
> An ORDER BY clause wihch combines both column references and expressions causes the
> sort engine to throw an ASSERT failure in sane builds.
> Here's a repro script:
> -bash-2.05b$ java org.apache.derby.tools.ij
> ij version 10.3
> ij> connect 'jdbc:derby:brydb;create=true';
> ij> create table t (a int, b int, c int, d int);
> 0 rows inserted/updated/deleted
> ij> insert into t values (1, 2, 3, 4);
> 1 row inserted/updated/deleted
> ij> select * from t order by a, b, c+2;
> ERROR XJ001: Java exception: 'ASSERT FAILED column ordering error: org.apache.derby.shared.common.sanity.AssertFailure'.
> As a first theory to check, I believe that when columns in the ORDER BY clause go through
"pullup" processing,
> they are generated into the select statement's ResultColumnList and then are later removed
at bind time because
> they are determined to duplicate the columns implicitly selected by the "*" column list.
But the expression "c+2" is not
> removed from the result list because it does not duplicate any existing column in the
table. During this processing,
> I think that the field "addedColumnOffset" in class OrderByColumn is not managed correctly
and ends up generating
> a bogus column position for the "c+2" column (it doesn't reflect that pulled-up columns
"a" and "b" have disappeared
> from the ResultColumnList), causing the sanity assertion at execution time.
> I stumbled across this problem while writing regression tests for DERBY-147, but the
problem occurs
> with or without the DERBY-147 fix, so I decided to log it as a separate problem.

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


Mime
View raw message