db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (DERBY-1030) In some situations a RETURNS NULL ON NULL function is called when one ot its parameters is NULL
Date Wed, 02 Dec 2009 13:16:21 GMT

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

Rick Hillegas edited comment on DERBY-1030 at 12/2/09 1:14 PM:
---------------------------------------------------------------

The bug is caused by an optimization intended to eliminate needless switching between the
Java domain and the SQL domain.

Two compile-time classes manage this switching:

JavaToSQLNode - This class is responsible for the reverse operation, that is, for changing
Java data values into SQL data values that can be used by other expressions in the query.
So for instance, this class is responsible for compiling the code which changes Integer and
primitive int into SQLInteger.

SQLToJavaNode - This class is responsible for turning SQL data values into Java data values
before they are passed as arguments to Java methods. So for instance, this class is responsible
for compiling the runtime code which changes a SQLInteger into a primitive int before invoking
a Java method.


SQLToJavaNode also compiles the NULL ON NULL INPUT check: If the SQL data value is going to
be used as the argument to a NULL ON NULL INPUT routine, then the SQLToJavaNode compiles short-circuiting
logic that prevents the routine from being called if the SQL data value is null.

Some performance can be lost when switching between the Java and SQL domains. We eliminate
this switching if a Java data value becomes a SQL data value only to become a Java data value
immediately afterwards. This happens when the return value of a Function is passed as an argument
to another Routine. E.g.:

  values ( outerFunction( innerFunction( 1 ) ) )

In this case the AST shows a SQLToJavaNode wrapping a JavaToSQLNode returned by innerFunction.
An optimization was put in to eliminate both conversion nodes in this case and to pass the
return value of innerFunction directly as an argument to outerFunction.

This optimization has a couple problems:

1) If innerFunction is a NULL ON NULL INPUT Function and innerFunction is called with null
inputs, then Derby tries to pass a null to outerFunction. This produces a verification error
if outerFunction takes primitive arguments. DERBY-479 fixes this by eliminating the optimization
in this case.

2) If outerFunction is a NULL ON NULL INPUT Function, then the elimination of the SQLToJavaNode
means that the NULL ON NULL INPUT check is not performed. This is the bug described by this
JIRA.

The fix is to also eliminate the optimization if the outer function is NULL ON NULL INPUT.


      was (Author: rhillegas):
    The bug is caused by an optimization intended to eliminate needless switching between
the Java domain and the SQL domain.

Two compile-time classes manage this switching:

JavaToSQLNode - This class is responsible for turning SQL data values into Java data values
before they are passed as arguments to Java methods. So for instance, this class is responsible
for compiling the runtime code which changes a SQLInteger into a primitive int before invoking
a Java method.

SQLToJavaNode - This class is responsible for the reverse operation, that is, for changing
Java data values into SQL data values that can be used by other expressions in the query.
So for instance, this class is responsible for compiling the code which changes Integer and
primitive int into SQLInteger.


SQLToJavaNode also compiles the NULL ON NULL INPUT check: If the SQL data value is going to
be used as the argument to a NULL ON NULL INPUT routine, then the SQLToJavaNode compiles short-circuiting
logic that prevents the routine from being called if the SQL data value is null.

Some performance can be lost when switching between the Java and SQL domains. We eliminate
this switching if a Java data value becomes a SQL data value only to become a Java data value
immediately afterwards. This happens when the return value of a Function is passed as an argument
to another Routine. E.g.:

  values ( outerFunction( innerFunction( 1 ) ) )

In this case the AST shows a SQLToJavaNode wrapping a JavaToSQLNode returned by innerFunction.
An optimization was put in to eliminate both conversion nodes in this case and to pass the
return value of innerFunction directly as an argument to outerFunction.

This optimization has a couple problems:

1) If innerFunction is a NULL ON NULL INPUT Function and innerFunction is called with null
inputs, then Derby tries to pass a null to outerFunction. This produces a verification error
if outerFunction takes primitive arguments. DERBY-479 fixes this by eliminating the optimization
in this case.

2) If outerFunction is a NULL ON NULL INPUT Function, then the elimination of the SQLToJavaNode
means that the NULL ON NULL INPUT check is not performed. This is the bug described by this
JIRA.

The fix is to also eliminate the optimization if the outer function is NULL ON NULL INPUT.

  
> In some situations a RETURNS NULL ON NULL function is called when one ot its parameters
is NULL
> -----------------------------------------------------------------------------------------------
>
>                 Key: DERBY-1030
>                 URL: https://issues.apache.org/jira/browse/DERBY-1030
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.1.2.1
>            Reporter: Daniel John Debrunner
>            Assignee: Rick Hillegas
>         Attachments: derby-1030-01-aa-disableOptimization.diff, derby479.java, derby479.sql
>
>
> The NULL argument to the function has to come from another function and that function's
Java method has to return a Java object type corresponding to a fixed length SQL type, such
as DATE, TIME and TIMESTAMP.
> Will attach repro scripts.

-- 
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