Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <27566939.129971284169774008.JavaMail.jira@thor>
Date: Fri, 10 Sep 2010 21:49:34 -0400 (EDT)
From: "Bryan Pendleton (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4798) NPE in nested outer join
In-Reply-To: <6595070.121481284135813142.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-4798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908262#action_12908262 ] 

Bryan Pendleton commented on DERBY-4798:
----------------------------------------

Following along the lines of DERBY-3097, perhaps there is some way that
NoPutResultSetImpl.clearOrderableCache() can check (numOpens == 0)
to be aware that the result set has not yet been opened, and can then
initialize the orderable cache in some other fashion (e.g., by calling
DataValueDescriptor.getNewNull() on the various Qualifier items in the cache?

I'm just throwing out ideas here, don't even know if they make any sense.

Alternatively, since this appears to have to do with *invariant* qualifiers, maybe
the code can check the qualifiers in the cache to see if they are variant or
invariant, and can make the getOrderable() call only for invariant qualifiers.
(Is it safe to call Qualifier.getOrderable for an invariant qualifier even if the
containing result set has not been opened yet?)


> NPE in nested outer join
> ------------------------
>
>                 Key: DERBY-4798
>                 URL: https://issues.apache.org/jira/browse/DERBY-4798
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.5.1.1, 10.5.2.0, 10.5.3.0, 10.6.1.0
>            Reporter: Dag H. Wanvik
>
> Using the schema from DERBY-4712 and running the original randomized query generator used to find DERBY-4712, http://code.google.com/p/h2database/source/browse/trunk/h2/src/test/org/h2/test/db/TestNestedJoins.java, I have uncovered yet another bug (NPE), which appears to be a different beast. This one is a regression in 10.5 (works in 10.4 and older). This is the failing query:
> SELECT t0.x0,
>        t1.x1,
>        t2.x2,
>        t3.x3,
>        t4.x4,
>        t5.x5,
>        t6.x6,
>        t7.x7
> FROM ((t0
>          LEFT OUTER JOIN ((t1
>                            LEFT OUTER JOIN (t2
>                                             LEFT OUTER JOIN t3
>                                               ON t2.x2 = t3.x3 )
>                              ON t1.x1 = t2.x2 )
>                           LEFT OUTER JOIN (t4
>                                            INNER JOIN (t5
>                                                        LEFT OUTER JOIN t6
>                                                          ON t5.x5 = t6.x6 )
>                                              ON t4.x4 = t5.x5 )
>                             ON t1.x1 = t5.x5 )
>            ON t0.x0 = t5.x5 )
>         LEFT OUTER JOIN t7
>           ON t3.x3 = t7.x7 ); 
> Relevant part of the stack trace (using 10.5 trunk @ svn 995846):
> Caused by: java.lang.NullPointerException
> 	at org.apache.derby.impl.sql.execute.BaseActivation.getColumnFromRow(BaseActivation.java:1458)
> 	at org.apache.derby.exe.ac4ac48095x012axfc73x9c5dx000003d485d847.e19(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.apache.derby.impl.services.reflect.ReflectMethod.invoke(ReflectMethod.java:46)
> 	at org.apache.derby.impl.sql.execute.GenericQualifier.getOrderable(GenericQualifier.java:96)
> 	at org.apache.derby.impl.sql.execute.NoPutResultSetImpl.clearOrderableCache(NoPutResultSetImpl.java:307)
> 	at org.apache.derby.impl.sql.execute.HashScanResultSet.resetProbeVariables(HashScanResultSet.java:359)
> 	at org.apache.derby.impl.sql.execute.HashScanResultSet.openCore(HashScanResultSet.java:322)
> 	at org.apache.derby.impl.sql.execute.JoinResultSet.openRight(JoinResultSet.java:283)
> 	at org.apache.derby.impl.sql.execute.JoinResultSet.openCore(JoinResultSet.java:152)
> 	at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(ProjectRestrictResultSet.java:181)
> 	at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(BasicNoPutResultSetImpl.java:251)
> 	at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:416)

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