[
https://issues.apache.org/jira/browse/DERBY-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-3652:
---------------------------------
Derby Info: [Existing Application Impact, Release Note Needed]
Marking the "Existing Application Impact" and "Release Note Needed" boxes.
Fixing signature matching may affect existing applications as follows:
1) Routines which previously failed to match may now successfully match user
methods. I believe there is only a low probability that this will break
existing applications.
2) Routines which previously matched one user overload may now match another. I
think the probability that this will break existing applications is greater but
still low. However, the consequences of this change may be subtle mistakes
which are not noticed for a long time.
3) Routines which previously matched a user method may now not match at all. I
think it is probable that this will break some existing applications.
4) Routines which previously matched a single user method may now match more
than one method and so raise an error. This situation has turned up in Derby's
own code. I think it is probable that this will break some existing
applications.
The workaround for these problems is to recode affected applications to conform
to the SQL standard behavior.
I feel that these discrepancies are analogous to the following other kinds of
fixes:
(1) is similar to fixing a query which used to raise an exception but now
succeeds.
(2) is similar to fixing a query so that it now returns a different set of
results.
(3) and (4) are similar to fixing a syntax error which had allowed or even
forced users to write illegal SQL.
> 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-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.
