Derby does not follow the SQL Standard when trying to map SQL routines to Java
methods.
---------------------------------------------------------------------------------------
Key: DERBY-3652
URL: https://issues.apache.org/jira/browse/DERBY-3652
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.5.0.0
Reporter: Rick Hillegas
I have only tested this in the 10.5 trunk. However, I suspect that this affects
all previous releases of Derby as well.
In resolving method signatures for function/procedure invocations, the SQL
standard makes the following definitions in part 13, section 4.5 (parameter
mapping). These definitions, in turn, refer to tables B-1 and B-3 in JDBC 3.0
Specification, Final Release, October 2001 ([JDBC]).
* Simply mappable - This refers to the correspondence of SQL and Java types
described in [JDBC] table B-1. This is the table which defines the mapping of
SQL types to Java primitives.
* Object mappable - This refers to the correspondence of SQL and Java types
described in [JDBC] table B-3. This is the table which defines the mapping of
SQL types to Java wrapper objects.
* Output mappable - For OUT and INOUT parameters, this refers to a single
element array whose cell is simply mappable or object mappable. E.g. Integer[]
or float[].
* Mappable - This means simply, object, or output mappable.
* Result set mappable - This means a single element array whose cell is a
type which implements either java.sql.ResultSet or
sqlj.runtime.ResultSetIterator.
Putting all of this together, section 4.5 continues:
"A Java method with M parameters is mappable (to SQL) if and only if, for
some N, 0 (zero) <= N <= M, the data types of the first N parameters are
mappable, the last M - N parameters are result set mappable, and the result
type is either simply mappable, object mappable, or void."
Section 8.6 gives more detailed rules, but they are hard to follow. According
to section 8.6, when resolving a routine invocation, Derby should expect to
find one and only one static mappable method with the expected external name
(Java class + method name).
I believe that this is a fair description of the rules. This, at least, is what
some other databases appear to do. See, for instance,
http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.ase_15.0.java/html/java/java126.htm
and
http://www.service-architecture.com/database/articles/mapping_sql_and_java_data_types.html
We do not have a regression test which verifies that Derby applies the SQL
standard resolution rules. There may be several divergences from the standard.
This JIRA is a place to track those discrepancies. Here is one that I have
noticed:
The following SQL signature
( a int ) returns int
should be mappable to any of the following Java signatures
public static int f( int a )
public static int f( Integer a )
public static Integer f( int a )
public static Integer f( Integer a )
However, I observe that Derby is only able to resolve the first and third
signatures (the ones with primitive arguments). I will attach a test case
showing this problem.
I will also attach an html table summarizing the simply and object mappable
rules.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
