[
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-01-ad-mixTypesOnFirstPass.diff
Attaching a new rev of the patch for making it possible to mix primitives with
wrapper types: derby-3652-01-ad-mixTypeOnFirstPass.diff. This is the same
approach as the previous patch and, in addition, this version adds regression
tests. Many of the tests have been commented out because of other bugs in
signature matching which need to be fixed. Touches the following files:
M java/engine/org/apache/derby/iapi/services/loader/ClassInspector.java
This is the change to signature matching, making it possible to mix primitives
and wrappers per the ANSI spec.
M java/engine/org/apache/derby/catalog/IndexDescriptor.java
M java/engine/org/apache/derby/catalog/types/IndexDescriptorImpl.java
M
java/engine/org/apache/derby/impl/sql/compile/UnaryComparisonOperatorNode.java
M java/engine/org/apache/derby/iapi/sql/dictionary/IndexRowGenerator.java
These edits remove the extra overload of getKeyColumnPosition() which caused a
signature ambiguity under the ANSI rules.
A
java/testing/org/apache/derbyTesting/functionTests/tests/lang/AnsiSignaturesTest.java
M java/testing/org/apache/derbyTesting/functionTests/tests/lang/_Suite.java
A
java/testing/org/apache/derbyTesting/functionTests/tests/lang/AnsiSignatures.java
These edits add a new set of regression tests (many commented out) to verify
that the ANSI rules are applied.
The new tests run cleanly for me standalone. I am now running the full
regression suites. If the tests pass, I am inclined to commit this patch and
move on to fixing other bugs in signature matching.
> 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-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.
