[jira] Commented: (DERBY-3652) Derby does not follow the SQL Standard when trying to map SQL routines to Java methods.
[ https://issues.apache.org/jira/browse/DERBY-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608572#action_12608572 ] Rick Hillegas commented on DERBY-3652: -- Checked in the signature matching lint tool. Committed derby-2652-10-aa-SignatureChecker.diff at subversion revision 672019. > 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-02-ab-dontWidenExceptForSmalllint.diff, > derby-3652-03-aa-dontWidenSmallint.diff, > derby-3652-03-ab-dontWidenSmallint.diff, > derby-3652-04-aa-deprecateJavaRules.diff, derby-3652-05-aa-moreTests.diff, > derby-3652-06-aa-dontWidenString.diff, > derby-3652-07-aa-dontWidenBigDecimal.diff, > derby-3652-08-aa-dontWidenAtAll.diff, derby-3652-09-aa-mixedTypes.diff, > derby-3652-10-aa-SignatureChecker.diff, derby-3652-11-aa-binaryTests.diff, > derby-3652-badmatches.diff, SignatureMapping.html, 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.
[jira] Commented: (DERBY-3652) Derby does not follow the SQL Standard when trying to map SQL routines to Java methods.
[ https://issues.apache.org/jira/browse/DERBY-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600915#action_12600915 ] Rick Hillegas commented on DERBY-3652: -- Tests ran cleanly for me on Java 5. I also ran AnsiSignatureTest and RoutineTest on a Java ME platform and they passed cleanly with this patch. I'm cautiously hopeful that this patch will fix DERBY-3697. Committed derby-3652-08-aa-dontWidenAtAll.diff at subversion revision 661469. > 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-02-ab-dontWidenExceptForSmalllint.diff, > derby-3652-03-aa-dontWidenSmallint.diff, > derby-3652-03-ab-dontWidenSmallint.diff, > derby-3652-04-aa-deprecateJavaRules.diff, derby-3652-05-aa-moreTests.diff, > derby-3652-06-aa-dontWidenString.diff, > derby-3652-07-aa-dontWidenBigDecimal.diff, > derby-3652-08-aa-dontWidenAtAll.diff, derby-3652-badmatches.diff, > SignatureMapping.html, 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.
[jira] Commented: (DERBY-3652) Derby does not follow the SQL Standard when trying to map SQL routines to Java methods.
[ https://issues.apache.org/jira/browse/DERBY-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600224#action_12600224 ] Rick Hillegas commented on DERBY-3652: -- Tests ran cleanly for me. Committed derby-3652-07-aa-dontWidenBigDecimal at subversion revision 660630. > 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-02-ab-dontWidenExceptForSmalllint.diff, > derby-3652-03-aa-dontWidenSmallint.diff, > derby-3652-03-ab-dontWidenSmallint.diff, > derby-3652-04-aa-deprecateJavaRules.diff, derby-3652-05-aa-moreTests.diff, > derby-3652-06-aa-dontWidenString.diff, > derby-3652-07-aa-dontWidenBigDecimal.diff, derby-3652-badmatches.diff, > SignatureMapping.html, 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.
[jira] Commented: (DERBY-3652) Derby does not follow the SQL Standard when trying to map SQL routines to Java methods.
[ https://issues.apache.org/jira/browse/DERBY-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598763#action_12598763 ] Rick Hillegas commented on DERBY-3652: -- Committed derby-3652-06-aa-dontWidenString.diff at subversion revision 658822. The tests ran cleanly for me except for an error in NetworkServerMBeanTest. The error does not recur when I run that test standalone. I believe there is an instability in this test: 1) testAttributeAccumulatedConnectionCount(org.apache.derbyTesting.functionTests.tests.management.NetworkServerMBeanTest)java.security.PrivilegedActionException: javax.management.InstanceNotFoundException: org.apache.derby:type=NetworkServer,system=c013800d-011a-0cdb-4f56-e1d7aa3e 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-011a-0cdb-4f56-e1d7aa3e 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: 8079, Failures: 0, Errors: 1 > 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-02-ab-dontWidenExceptForSmalllint.diff, > derby-3652-03-aa-dontWidenSmallint.diff, > derby-3652-03-ab-dontWidenSmallint.diff, > derby-3652-04-aa-deprecateJavaRules.diff, derby-3652-05-aa-moreTests.diff, > derby-3652-06-aa-dontWidenString.diff, derby-3652-badmatches.diff, > SignatureMapping.html, 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 map
[jira] Commented: (DERBY-3652) Derby does not follow the SQL Standard when trying to map SQL routines to Java methods.
[ https://issues.apache.org/jira/browse/DERBY-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598688#action_12598688 ] Rick Hillegas commented on DERBY-3652: -- Regression tests ran cleanly for me. Committed derby-3652-04-aa-deprecateJavaRules.diff at subversion revision 658730. > 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-02-ab-dontWidenExceptForSmalllint.diff, > derby-3652-03-aa-dontWidenSmallint.diff, > derby-3652-03-ab-dontWidenSmallint.diff, > derby-3652-04-aa-deprecateJavaRules.diff, derby-3652-badmatches.diff, > SignatureMapping.html, 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.
[jira] Commented: (DERBY-3652) Derby does not follow the SQL Standard when trying to map SQL routines to Java methods.
[ https://issues.apache.org/jira/browse/DERBY-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598461#action_12598461 ] Rick Hillegas commented on DERBY-3652: -- Committed derby-3652-03-ab-dontWidenSmallint.diff at subversion revision 658427. Regression tests passed cleanly for me. > 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-02-ab-dontWidenExceptForSmalllint.diff, > derby-3652-03-aa-dontWidenSmallint.diff, > derby-3652-03-ab-dontWidenSmallint.diff, derby-3652-badmatches.diff, > SignatureMapping.html, 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.
[jira] Commented: (DERBY-3652) Derby does not follow the SQL Standard when trying to map SQL routines to Java methods.
[ https://issues.apache.org/jira/browse/DERBY-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598286#action_12598286 ] Rick Hillegas commented on DERBY-3652: -- Committed derby-3562-02-ab-dontWidenExceptForSmallint.diff at subversion revision 658232. The regression tests ran cleanly for me on this one. > 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-02-ab-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.
[jira] Commented: (DERBY-3652) Derby does not follow the SQL Standard when trying to map SQL routines to Java methods.
[ https://issues.apache.org/jira/browse/DERBY-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597945#action_12597945 ] Rick Hillegas commented on DERBY-3652: -- Committed derby-3652-01-ad-mixTypeOnFirstPass.diff at subversion revision 657819. > 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.
[jira] Commented: (DERBY-3652) Derby does not follow the SQL Standard when trying to map SQL routines to Java methods.
[ 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-e1d7aa3e 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-e1d7aa3e 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, sect
[jira] Commented: (DERBY-3652) Derby does not follow the SQL Standard when trying to map SQL routines to Java methods.
[ https://issues.apache.org/jira/browse/DERBY-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597708#action_12597708 ] Thomas Nielsen commented on DERBY-3652: --- Changes look ok, and regression tests pass. +1 to commit. > 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.
[jira] Commented: (DERBY-3652) Derby does not follow the SQL Standard when trying to map SQL routines to Java methods.
[ https://issues.apache.org/jira/browse/DERBY-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595289#action_12595289 ] Rick Hillegas commented on DERBY-3652: -- Thanks for test-driving the patch, Thomas. I am still working on a systematic regression test for this behavior but I'm back-logged because of Java One this week. > 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: derby-3652-01-aa-mixTypesOnFirstPass.diff, > derby-3652-01-ab-mixTypesOnFirstPass.diff, > derby-3652-01-ac-mixTypesOnFirstPass.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.
[jira] Commented: (DERBY-3652) Derby does not follow the SQL Standard when trying to map SQL routines to Java methods.
[ https://issues.apache.org/jira/browse/DERBY-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595154#action_12595154 ] Thomas Nielsen commented on DERBY-3652: --- Even though it does not have "patch available" checked, I went ahead and tested the third patch. Regression tests run sucessfully for me as well, and the patch fixes the broken behavior for int/Integer mapping. I extended the attached SignatureProblems.java and accompanying sql script with double/Double conversions and they work fine with the patch too. +1 to commit the third patch as is, and follow up later with a proper test case. > 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: derby-3652-01-aa-mixTypesOnFirstPass.diff, > derby-3652-01-ab-mixTypesOnFirstPass.diff, > derby-3652-01-ac-mixTypesOnFirstPass.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.
[jira] Commented: (DERBY-3652) Derby does not follow the SQL Standard when trying to map SQL routines to Java methods.
[ https://issues.apache.org/jira/browse/DERBY-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593906#action_12593906 ] Rick Hillegas commented on DERBY-3652: -- The regression tests pass with the third rev of the patch too. > 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: derby-3652-01-aa-mixTypesOnFirstPass.diff, > derby-3652-01-ab-mixTypesOnFirstPass.diff, > derby-3652-01-ac-mixTypesOnFirstPass.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.
[jira] Commented: (DERBY-3652) Derby does not follow the SQL Standard when trying to map SQL routines to Java methods.
[ https://issues.apache.org/jira/browse/DERBY-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593838#action_12593838 ] Daniel John Debrunner commented on DERBY-3652: -- I would advise approach 1) I would guess there is no path to call the methods with the Integer signature. > 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: derby-3652-01-aa-mixTypesOnFirstPass.diff, > derby-3652-01-ab-mixTypesOnFirstPass.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.
