db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-1861) Column ordering ASSERT when combining column references and expressions in same ORDER BY
Date Tue, 20 Mar 2007 21:19:33 GMT

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

A B commented on DERBY-1861:

Hi Bryan,

There's one thing that I missed when reviewing your changes--and I only just now noticed it
by sheer accident.

In order to get some numbers for DERBY-47 I did an INSANE build and then tried to build jars.
 The building of the jars was successful, but I just happened to notice one unusal line in
the output, namely:

     [echo]  creating derby.jar class list
     [java] SANITY >>> /org/apache/derby/impl/sql/compile/ResultColumnList.class
     [echo]  creating new DBMS.properties file

Confused by this, I opened ResultColumnList.java and did a search for SanityManager--and it
turns out that the patch for this issue adds a call to SanityManager.THROWASSERT that is *not*
contained inside an "if (SanityManager.DEBUG)" block.

Apparently this isn't a big deal since all of the nightly tests have been running just fine--but
for the sake of correctness, I think we need to wrap the THROWASSERT call inside a SanityManager.DEBUG
check.  It's a one-line change that should be easy enough to make (esp. since you're a committer...

> Column ordering ASSERT when combining column references and expressions in same ORDER
> ----------------------------------------------------------------------------------------
>                 Key: DERBY-1861
>                 URL: https://issues.apache.org/jira/browse/DERBY-1861
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions:
>            Reporter: Bryan Pendleton
>         Assigned To: Bryan Pendleton
>            Priority: Minor
>             Fix For:
>         Attachments: adjustOffsets_v1.diff, adjustOffsets_v2_moreJavaDoc.diff, dataStructureNotes.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.

View raw message