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

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

Rick Hillegas commented on DERBY-3652:
--------------------------------------

Thanks for running the tests, Thomas. I saw one problem when I ran the tests:

1) testAttributeAccumulatedConnectionCount(org.apache.derbyTesting.functionTests.tests.management.NetworkServerMBeanTest)java.security.PrivilegedActionException:
javax.management.InstanceNotFoundException: org.apache.derby:type=NetworkServer,system=c013800d-0119-f43a-1ef1-ffffe1d7aa3e
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getAttribute(MBeanTest.java:379)
	at org.apache.derbyTesting.functionTests.tests.management.NetworkServerMBeanTest.testAttributeAccumulatedConnectionCount(NetworkServerMBeanTest.java:93)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:103)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
	at junit.extensions.TestSetup.run(TestSetup.java:25)
	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
	at junit.extensions.TestSetup.run(TestSetup.java:25)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
	at junit.extensions.TestSetup.run(TestSetup.java:25)
	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
Caused by: javax.management.InstanceNotFoundException: org.apache.derby:type=NetworkServer,system=c013800d-0119-f43a-1ef1-ffffe1d7aa3e
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1010)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:627)
	at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:659)
	at org.apache.derbyTesting.functionTests.tests.management.MBeanTest$4.run(MBeanTest.java:382)
	... 41 more

FAILURES!!!
Tests run: 8062,  Failures: 0,  Errors: 1

When I re-ran NetworkServerMBeanTest standalone, it passed. Since the tests ran cleanly for
Thomas, I'm inclined to believe that there is an instability in NetworkServerMBeanTest  that
is not related to this patch.

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


Mime
View raw message