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] Updated: (DERBY-3652) Derby does not follow the SQL Standard when trying to map SQL routines to Java methods.
Date Mon, 19 May 2008 17:15:55 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Rick Hillegas updated DERBY-3652:
---------------------------------

    Attachment: derby-3652-02-aa-dontWidenExceptForSmalllint.diff

Attaching derby-3652-02-aa-dontWidenExceptForSmallint.diff. This removes code which was matching
small numeric args to bigger Java types. For instance, SQL INTEGER was able to match Java
long. I removed this bad matching logic for INTEGER, BIGINT, REAL, and DOUBLE.

When I removed the corresponding logic for SMALLINT, method resolution broke when CleanDatabaseTestSetup
tried to call the system procedure SYSCS_INPLACE_COMPRESS_TABLE. According to the Reference
Manual, the numeric arguments of this procedure are typed as SMALLINT. According to the ANSI
rules, those args can match Java args of type short or java.lang.Integer. The Java signature
for that method, however, presents int as the type of its numeric args. I think that the solution
may be to redeclare the signatures of various Java methods in SystemProcedures so that they
will match, under the ANSI rules, with the signatures described in the Reference Manual.

In addition, the logic in ClassInspector.classConvertableFromTo() looks like it may match
SQL character types to Java numeric types. This would violate the ANSI rules too. This needs
to be looked into later.

The signature test runs cleanly for me standalone. I will run the complete regression suites
and see what breaks. Touches the following files:

M      java/engine/org/apache/derby/iapi/services/loader/ClassInspector.java

Changes  ClassInspector.classConvertableFromTo() to not match smaller numeric types to larger
numeric types.

M      java/testing/org/apache/derbyTesting/functionTests/tests/lang/AnsiSignaturesTest.java

Uncommented most of the tests for signatures which are not supposed to find any matches.


> 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
>         Attachments: badsignatures.sql, derby-3652-01-aa-mixTypesOnFirstPass.diff, derby-3652-01-ab-mixTypesOnFirstPass.diff,
derby-3652-01-ac-mixTypesOnFirstPass.diff, derby-3652-01-ad-mixTypesOnFirstPass.diff, derby-3652-02-aa-dontWidenExceptForSmalllint.diff,
derby-3652-badmatches.diff, SignatureMapping.html, SignatureMapping.html, SignatureProblems.java,
signatureProblems.sql
>
>
> 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.


Mime
View raw message