[jira] [Commented] (DERBY-6224) Many test failures on latest JDK 8 EA build because of missing SQLPermission
[ https://issues.apache.org/jira/browse/DERBY-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13677036#comment-13677036 ] ASF subversion and git services commented on DERBY-6224: Commit 1490291 from [~knutanders] [ https://svn.apache.org/r1490291 ] DERBY-6224: Many test failures on latest JDK 8 EA build because of missing SQLPermission Merged fix from trunk (revision 1488125). Many test failures on latest JDK 8 EA build because of missing SQLPermission Key: DERBY-6224 URL: https://issues.apache.org/jira/browse/DERBY-6224 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.11.0.0 Environment: java version 1.8.0-ea Java(TM) SE Runtime Environment (build 1.8.0-ea-b89) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b31, mixed mode) Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.10.1.2, 10.11.0.0 Attachments: derby-6224-01-a.diff, derby-6224-01-b.diff With the latest EA build of JDK 8 (build 1.8.0-ea-b89), I see many failures in suites.All. For example: 1) testStartNetworkServerFalse(org.apache.derbyTesting.functionTests.tests.derbynet.DerbyNetAutoStartTest)java.security.AccessControlException: access denied (java.sql.SQLPermission deregisterDriver) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:364) at java.security.AccessController.checkPermission(AccessController.java:562) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.sql.DriverManager.deregisterDriver(DriverManager.java:399) at org.apache.derby.jdbc.AutoloadedDriver.unregisterDriverModule(AutoloadedDriver.java:263) at org.apache.derby.jdbc.Driver20.stop(Driver20.java:105) at org.apache.derby.impl.services.monitor.TopService.stop(TopService.java:443) at org.apache.derby.impl.services.monitor.TopService.shutdown(TopService.java:394) at org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(BaseMonitor.java:227) at org.apache.derby.impl.services.monitor.FileMonitor.shutdown(FileMonitor.java:44) at org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(BaseMonitor.java:197) at org.apache.derby.impl.services.monitor.FileMonitor.shutdown(FileMonitor.java:44) at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:255) at org.apache.derby.jdbc.Driver20.connect(Driver20.java:246) at org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:145) at java.sql.DriverManager.getConnection(DriverManager.java:661) at java.sql.DriverManager.getConnection(DriverManager.java:208) at org.apache.derbyTesting.junit.DriverManagerConnector.getConnectionByAttributes(DriverManagerConnector.java:204) at org.apache.derbyTesting.junit.DriverManagerConnector.shutEngine(DriverManagerConnector.java:171) at org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1822) at org.apache.derbyTesting.functionTests.tests.derbynet.DerbyNetAutoStartTest.setUp(DerbyNetAutoStartTest.java:82) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) What's new in EA build 89 is that DriverManager.deregisterDriver() now requires an SQLPermission when running under a security manager. Most of suites.All runs under a security manager, and Derby's engine shutdown code calls deregisterDriver(), so this problem probably affects all tests that shut down the engine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6246) convert i18n/urlLocale.sql to JUnit
[ https://issues.apache.org/jira/browse/DERBY-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678134#comment-13678134 ] ASF subversion and git services commented on DERBY-6246: Commit 1490716 from [~kmarsden] [ https://svn.apache.org/r1490716 ] DERBY-6246 convert i18n/urlLocale.sql to JUnit convert i18n/urlLocale.sql to JUnit Key: DERBY-6246 URL: https://issues.apache.org/jira/browse/DERBY-6246 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.10.1.1 Reporter: Kathey Marsden Attachments: derby-6246_diff2.txt, derby-6246_diff.txt Convert i18n/urlLocale.sql to JUnit so that it passes on z/os. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6256) Move the XmlVTI into the product.
[ https://issues.apache.org/jira/browse/DERBY-6256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678352#comment-13678352 ] ASF subversion and git services commented on DERBY-6256: Commit 1490799 from [~rhillegas] [ https://svn.apache.org/r1490799 ] DERBY-6256: Commit derby-6256-01-aa-move-XmlVTI-into-product.diff, moving the XmlVTI into the vti package of the product. Move the XmlVTI into the product. - Key: DERBY-6256 URL: https://issues.apache.org/jira/browse/DERBY-6256 Project: Derby Issue Type: Improvement Components: SQL, Tools Affects Versions: 10.11.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: derby-6256-01-aa-move-XmlVTI-into-product.diff The XmlVTI under derbyDemo has been useful to me for many years. It has become even more useful now that Derby supports varargs. That is because varargs make it very easy to declare an XmlVTI. At this point, I think it is worth re-phrasing the XmlVTI in terms of varargs and moving it into the product so that we can use it for internal table functions. There is no rush to expose XmlVTI as part of Derby's public api, but we could consider doing that if other people find this table function to be useful. The XmlVTI is a table function which turns an xml file into a tabular data set which you can query via sql. When you declare an XmlVTI, you state the following arguments: 1) The url of an xml file. 2) The name of the element in the xml file which you want to treat as a record or row. 3) The names of the attributes and subelements of that record which you want to treat as columns. Now that we have varargs, it is possible to represent this trailing argument as a variable length argument list. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6246) convert i18n/urlLocale.sql to JUnit
[ https://issues.apache.org/jira/browse/DERBY-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13679372#comment-13679372 ] ASF subversion and git services commented on DERBY-6246: Commit 1491364 from [~knutanders] [ https://svn.apache.org/r1491364 ] DERBY-6246: Fix javadoc warning convert i18n/urlLocale.sql to JUnit Key: DERBY-6246 URL: https://issues.apache.org/jira/browse/DERBY-6246 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.10.1.1 Reporter: Kathey Marsden Assignee: Kathey Marsden Fix For: 10.11.0.0 Attachments: derby-6246_diff2.txt, derby-6246_diff.txt Convert i18n/urlLocale.sql to JUnit so that it passes on z/os. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6254) Reduce number of factory methods in StandardException
[ https://issues.apache.org/jira/browse/DERBY-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13679373#comment-13679373 ] ASF subversion and git services commented on DERBY-6254: Commit 1491366 from [~knutanders] [ https://svn.apache.org/r1491366 ] DERBY-6254: Reduce number of factory methods in StandardException Generalize the factory methods by using varargs. Reduce number of factory methods in StandardException - Key: DERBY-6254 URL: https://issues.apache.org/jira/browse/DERBY-6254 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.11.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: derby-6254-01-a.diff StandardException has many factory methods for creating exceptions and warnings. For example, there are newException() methods for 0 to 8 message arguments. A single method taking a vararg argument could replace those nine methods. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6256) Move the XmlVTI into the product.
[ https://issues.apache.org/jira/browse/DERBY-6256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13679570#comment-13679570 ] ASF subversion and git services commented on DERBY-6256: Commit 1491490 from [~rhillegas] [ https://svn.apache.org/r1491490 ] DERBY-6256: Commit derby-6256-02-aa-allowParentTags.diff, allowing XmlVTIs to inherit columns from outer xml elements in which the primary row element is nested. Move the XmlVTI into the product. - Key: DERBY-6256 URL: https://issues.apache.org/jira/browse/DERBY-6256 Project: Derby Issue Type: Improvement Components: SQL, Tools Affects Versions: 10.11.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: derby-6256-01-aa-move-XmlVTI-into-product.diff, derby-6256-02-aa-allowParentTags.diff The XmlVTI under derbyDemo has been useful to me for many years. It has become even more useful now that Derby supports varargs. That is because varargs make it very easy to declare an XmlVTI. At this point, I think it is worth re-phrasing the XmlVTI in terms of varargs and moving it into the product so that we can use it for internal table functions. There is no rush to expose XmlVTI as part of Derby's public api, but we could consider doing that if other people find this table function to be useful. The XmlVTI is a table function which turns an xml file into a tabular data set which you can query via sql. When you declare an XmlVTI, you state the following arguments: 1) The url of an xml file. 2) The name of the element in the xml file which you want to treat as a record or row. 3) The names of the attributes and subelements of that record which you want to treat as columns. Now that we have varargs, it is possible to represent this trailing argument as a variable length argument list. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6255) convert i18n/messageLocale.sql
[ https://issues.apache.org/jira/browse/DERBY-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13679693#comment-13679693 ] ASF subversion and git services commented on DERBY-6255: Commit 1491542 from [~kmarsden] [ https://svn.apache.org/r1491542 ] DERBY-6255 convert i18n/messageLocale.sql convert i18n/messageLocale.sql -- Key: DERBY-6255 URL: https://issues.apache.org/jira/browse/DERBY-6255 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.10.1.1 Reporter: Kathey Marsden Attachments: derby-6255_diff.txt Convert i18n/messageLocale.sql -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6251) nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified.
[ https://issues.apache.org/jira/browse/DERBY-6251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13679770#comment-13679770 ] ASF subversion and git services commented on DERBY-6251: Commit 1491566 from [~myrna] [ https://svn.apache.org/r1491566 ] DERBY-6251; disabling test run with weme jvm nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified. Key: DERBY-6251 URL: https://issues.apache.org/jira/browse/DERBY-6251 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.6.2.3, 10.7.1.4, 10.9.2.2 Environment: Generating report for RunSuite derbyall j9_foundation11 j9 null null true -- Java Information -- Java Version:WECE J2ME Foundation Specification v1.1 Java Vendor: IBM Corporation Java home: C:\jartest\weme6.2 Java classpath: C:/jartest/jars/derbyrun.jar;C:/jartest/jars/derbyTesting.jar;c:/jartest/tools/java/jakarta-oro-2.0.8.jar;c:/jartest/junit/junit.jar; OS name: Windows Server 2008 OS architecture: x86 OS version: 6.1 build 7601 Service Pack 1 Java user name: cloudtest Java user home: C:\Users\cloudtest Java user dir: C:\jartest\JarResults.2013-05-17\weme6.2_derbyall java.specification.name: J2ME Foundation Specification java.specification.version: 1.1 java.runtime.version: 2.4 java.fullversion: IBM J9 2.4 Windows Server 2008 x86-32 (JIT enabled, AOT enabled) J9VM - 20080919_023055_lHdFGQ JIT - r9.weme62_20080724_2131 GC - 20080609_AA - Derby Information [C:\jartest\jars\derby.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbytools.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbynet.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbyclient.jar] 10.9.2.2 - (1484050) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [cs] version: 10.9.2.2 - (1484050) Found support for locale: [de_DE] version: 10.9.2.2 - (1484050) Found support for locale: [es] version: 10.9.2.2 - (1484050) Found support for locale: [fr] version: 10.9.2.2 - (1484050) Found support for locale: [hu] version: 10.9.2.2 - (1484050) Found support for locale: [it] version: 10.9.2.2 - (1484050) Found support for locale: [ja_JP] version: 10.9.2.2 - (1484050) Found support for locale: [ko_KR] version: 10.9.2.2 - (1484050) Found support for locale: [pl] version: 10.9.2.2 - (1484050) Found support for locale: [pt_BR] version: 10.9.2.2 - (1484050) Found support for locale: [ru] version: 10.9.2.2 - (1484050) Found support for locale: [zh_CN] version: 10.9.2.2 - (1484050) Found support for locale: [zh_TW] version: 10.9.2.2 - (1484050) Reporter: Mike Matrigali failing consistently on one machine, 10.9, windows, weme - http://people.apache.org/~myrnavl/derby_test_results/v10_9/windows/testlog/weme6.2/1484050-derbyall_diff.txt *** Start: derbyrunjartest jdkWECE J2ME Foundation Specification v1.1 derbyall:derbytools 2013-05-17 23:02:07 *** 2 del Usage: java org.apache.derby.tools.ij [-p propertyfile] [inputfile] 2a2 Process exception: (2) The system cannot find the file specified. 4 del USAGE: java org.apache.derby.tools.sysinfo -cp [ [ embedded ][ server ][ client] [ tools ] [ anyClass.class ] ] 4a4 Process exception: (2) The system cannot find the file specified. 6 del USAGE: 7 del java org.apache.derby.tools.dblook -d sourceDBUrl [OPTIONS] 8 del where the source URL is the full URL, including the connection protocol 9 del and any connection attributes that might apply. For example, use 10 del 'jdbc:derby:myDB', or 'jdbc:derby://xxxFILTERED_HOSTNAMExxx:1527/myDB;user=usr;'. 11 del options include: 12 del -z schemaName to specify a schema to which the DDL generation 13 del should be limited. Only database objects with that schema will have 14 del their DDL generated. 15 del -t tableOne tableTwo ... to specify a list of tables for which 16 del the DDL will be generated; any tables not in the list will be ignored. 17 del -td value to specify what should be appended to the end 18 del of each DDL statement. 19 del This defaults to ';'. 20 del -noview to prevent the generation of DDL for views. 21 del -append to keep from overwriting the output files. 22 del -verbose to have error messages printed to the
[jira] [Commented] (DERBY-6251) nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified.
[ https://issues.apache.org/jira/browse/DERBY-6251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13679813#comment-13679813 ] ASF subversion and git services commented on DERBY-6251: Commit 1491577 from [~myrna] [ https://svn.apache.org/r1491577 ] DERBY-6251; nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified. backport of revision 1491566 from 10.9 nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified. Key: DERBY-6251 URL: https://issues.apache.org/jira/browse/DERBY-6251 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.6.2.3, 10.7.1.4, 10.9.2.2 Environment: Generating report for RunSuite derbyall j9_foundation11 j9 null null true -- Java Information -- Java Version:WECE J2ME Foundation Specification v1.1 Java Vendor: IBM Corporation Java home: C:\jartest\weme6.2 Java classpath: C:/jartest/jars/derbyrun.jar;C:/jartest/jars/derbyTesting.jar;c:/jartest/tools/java/jakarta-oro-2.0.8.jar;c:/jartest/junit/junit.jar; OS name: Windows Server 2008 OS architecture: x86 OS version: 6.1 build 7601 Service Pack 1 Java user name: cloudtest Java user home: C:\Users\cloudtest Java user dir: C:\jartest\JarResults.2013-05-17\weme6.2_derbyall java.specification.name: J2ME Foundation Specification java.specification.version: 1.1 java.runtime.version: 2.4 java.fullversion: IBM J9 2.4 Windows Server 2008 x86-32 (JIT enabled, AOT enabled) J9VM - 20080919_023055_lHdFGQ JIT - r9.weme62_20080724_2131 GC - 20080609_AA - Derby Information [C:\jartest\jars\derby.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbytools.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbynet.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbyclient.jar] 10.9.2.2 - (1484050) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [cs] version: 10.9.2.2 - (1484050) Found support for locale: [de_DE] version: 10.9.2.2 - (1484050) Found support for locale: [es] version: 10.9.2.2 - (1484050) Found support for locale: [fr] version: 10.9.2.2 - (1484050) Found support for locale: [hu] version: 10.9.2.2 - (1484050) Found support for locale: [it] version: 10.9.2.2 - (1484050) Found support for locale: [ja_JP] version: 10.9.2.2 - (1484050) Found support for locale: [ko_KR] version: 10.9.2.2 - (1484050) Found support for locale: [pl] version: 10.9.2.2 - (1484050) Found support for locale: [pt_BR] version: 10.9.2.2 - (1484050) Found support for locale: [ru] version: 10.9.2.2 - (1484050) Found support for locale: [zh_CN] version: 10.9.2.2 - (1484050) Found support for locale: [zh_TW] version: 10.9.2.2 - (1484050) Reporter: Mike Matrigali failing consistently on one machine, 10.9, windows, weme - http://people.apache.org/~myrnavl/derby_test_results/v10_9/windows/testlog/weme6.2/1484050-derbyall_diff.txt *** Start: derbyrunjartest jdkWECE J2ME Foundation Specification v1.1 derbyall:derbytools 2013-05-17 23:02:07 *** 2 del Usage: java org.apache.derby.tools.ij [-p propertyfile] [inputfile] 2a2 Process exception: (2) The system cannot find the file specified. 4 del USAGE: java org.apache.derby.tools.sysinfo -cp [ [ embedded ][ server ][ client] [ tools ] [ anyClass.class ] ] 4a4 Process exception: (2) The system cannot find the file specified. 6 del USAGE: 7 del java org.apache.derby.tools.dblook -d sourceDBUrl [OPTIONS] 8 del where the source URL is the full URL, including the connection protocol 9 del and any connection attributes that might apply. For example, use 10 del 'jdbc:derby:myDB', or 'jdbc:derby://xxxFILTERED_HOSTNAMExxx:1527/myDB;user=usr;'. 11 del options include: 12 del -z schemaName to specify a schema to which the DDL generation 13 del should be limited. Only database objects with that schema will have 14 del their DDL generated. 15 del -t tableOne tableTwo ... to specify a list of tables for which 16 del the DDL will be generated; any tables not in the list will be ignored. 17 del -td value to specify what should be appended to the end 18 del of each DDL statement. 19 del This defaults to ';'. 20 del -noview to prevent the generation
[jira] [Commented] (DERBY-6255) convert i18n/messageLocale.sql
[ https://issues.apache.org/jira/browse/DERBY-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13679850#comment-13679850 ] ASF subversion and git services commented on DERBY-6255: Commit 1491590 from [~kmarsden] [ https://svn.apache.org/r1491590 ] DERBY-6255 convert i18n/messageLocale.sql additional minor cleanup of use of literal extinout in UrlLocaleTest convert i18n/messageLocale.sql -- Key: DERBY-6255 URL: https://issues.apache.org/jira/browse/DERBY-6255 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.10.1.1 Reporter: Kathey Marsden Attachments: derby-6255_diff.txt Convert i18n/messageLocale.sql -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6251) nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified.
[ https://issues.apache.org/jira/browse/DERBY-6251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13679887#comment-13679887 ] ASF subversion and git services commented on DERBY-6251: Commit 1491594 from [~myrna] [ https://svn.apache.org/r1491594 ] DERBY-6251; nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified. backport of revision 1491566 from 10.9. nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified. Key: DERBY-6251 URL: https://issues.apache.org/jira/browse/DERBY-6251 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.6.2.3, 10.7.1.4, 10.9.2.2 Environment: Generating report for RunSuite derbyall j9_foundation11 j9 null null true -- Java Information -- Java Version:WECE J2ME Foundation Specification v1.1 Java Vendor: IBM Corporation Java home: C:\jartest\weme6.2 Java classpath: C:/jartest/jars/derbyrun.jar;C:/jartest/jars/derbyTesting.jar;c:/jartest/tools/java/jakarta-oro-2.0.8.jar;c:/jartest/junit/junit.jar; OS name: Windows Server 2008 OS architecture: x86 OS version: 6.1 build 7601 Service Pack 1 Java user name: cloudtest Java user home: C:\Users\cloudtest Java user dir: C:\jartest\JarResults.2013-05-17\weme6.2_derbyall java.specification.name: J2ME Foundation Specification java.specification.version: 1.1 java.runtime.version: 2.4 java.fullversion: IBM J9 2.4 Windows Server 2008 x86-32 (JIT enabled, AOT enabled) J9VM - 20080919_023055_lHdFGQ JIT - r9.weme62_20080724_2131 GC - 20080609_AA - Derby Information [C:\jartest\jars\derby.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbytools.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbynet.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbyclient.jar] 10.9.2.2 - (1484050) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [cs] version: 10.9.2.2 - (1484050) Found support for locale: [de_DE] version: 10.9.2.2 - (1484050) Found support for locale: [es] version: 10.9.2.2 - (1484050) Found support for locale: [fr] version: 10.9.2.2 - (1484050) Found support for locale: [hu] version: 10.9.2.2 - (1484050) Found support for locale: [it] version: 10.9.2.2 - (1484050) Found support for locale: [ja_JP] version: 10.9.2.2 - (1484050) Found support for locale: [ko_KR] version: 10.9.2.2 - (1484050) Found support for locale: [pl] version: 10.9.2.2 - (1484050) Found support for locale: [pt_BR] version: 10.9.2.2 - (1484050) Found support for locale: [ru] version: 10.9.2.2 - (1484050) Found support for locale: [zh_CN] version: 10.9.2.2 - (1484050) Found support for locale: [zh_TW] version: 10.9.2.2 - (1484050) Reporter: Mike Matrigali failing consistently on one machine, 10.9, windows, weme - http://people.apache.org/~myrnavl/derby_test_results/v10_9/windows/testlog/weme6.2/1484050-derbyall_diff.txt *** Start: derbyrunjartest jdkWECE J2ME Foundation Specification v1.1 derbyall:derbytools 2013-05-17 23:02:07 *** 2 del Usage: java org.apache.derby.tools.ij [-p propertyfile] [inputfile] 2a2 Process exception: (2) The system cannot find the file specified. 4 del USAGE: java org.apache.derby.tools.sysinfo -cp [ [ embedded ][ server ][ client] [ tools ] [ anyClass.class ] ] 4a4 Process exception: (2) The system cannot find the file specified. 6 del USAGE: 7 del java org.apache.derby.tools.dblook -d sourceDBUrl [OPTIONS] 8 del where the source URL is the full URL, including the connection protocol 9 del and any connection attributes that might apply. For example, use 10 del 'jdbc:derby:myDB', or 'jdbc:derby://xxxFILTERED_HOSTNAMExxx:1527/myDB;user=usr;'. 11 del options include: 12 del -z schemaName to specify a schema to which the DDL generation 13 del should be limited. Only database objects with that schema will have 14 del their DDL generated. 15 del -t tableOne tableTwo ... to specify a list of tables for which 16 del the DDL will be generated; any tables not in the list will be ignored. 17 del -td value to specify what should be appended to the end 18 del of each DDL statement. 19 del This defaults to ';'. 20 del -noview to prevent the generation
[jira] [Commented] (DERBY-6251) nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified.
[ https://issues.apache.org/jira/browse/DERBY-6251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13679935#comment-13679935 ] ASF subversion and git services commented on DERBY-6251: Commit 1491608 from [~myrna] [ https://svn.apache.org/r1491608 ] DERBY-6251; nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified. backport of revision 1491566 from 10.9 nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified. Key: DERBY-6251 URL: https://issues.apache.org/jira/browse/DERBY-6251 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.6.2.3, 10.7.1.4, 10.9.2.2 Environment: Generating report for RunSuite derbyall j9_foundation11 j9 null null true -- Java Information -- Java Version:WECE J2ME Foundation Specification v1.1 Java Vendor: IBM Corporation Java home: C:\jartest\weme6.2 Java classpath: C:/jartest/jars/derbyrun.jar;C:/jartest/jars/derbyTesting.jar;c:/jartest/tools/java/jakarta-oro-2.0.8.jar;c:/jartest/junit/junit.jar; OS name: Windows Server 2008 OS architecture: x86 OS version: 6.1 build 7601 Service Pack 1 Java user name: cloudtest Java user home: C:\Users\cloudtest Java user dir: C:\jartest\JarResults.2013-05-17\weme6.2_derbyall java.specification.name: J2ME Foundation Specification java.specification.version: 1.1 java.runtime.version: 2.4 java.fullversion: IBM J9 2.4 Windows Server 2008 x86-32 (JIT enabled, AOT enabled) J9VM - 20080919_023055_lHdFGQ JIT - r9.weme62_20080724_2131 GC - 20080609_AA - Derby Information [C:\jartest\jars\derby.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbytools.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbynet.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbyclient.jar] 10.9.2.2 - (1484050) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [cs] version: 10.9.2.2 - (1484050) Found support for locale: [de_DE] version: 10.9.2.2 - (1484050) Found support for locale: [es] version: 10.9.2.2 - (1484050) Found support for locale: [fr] version: 10.9.2.2 - (1484050) Found support for locale: [hu] version: 10.9.2.2 - (1484050) Found support for locale: [it] version: 10.9.2.2 - (1484050) Found support for locale: [ja_JP] version: 10.9.2.2 - (1484050) Found support for locale: [ko_KR] version: 10.9.2.2 - (1484050) Found support for locale: [pl] version: 10.9.2.2 - (1484050) Found support for locale: [pt_BR] version: 10.9.2.2 - (1484050) Found support for locale: [ru] version: 10.9.2.2 - (1484050) Found support for locale: [zh_CN] version: 10.9.2.2 - (1484050) Found support for locale: [zh_TW] version: 10.9.2.2 - (1484050) Reporter: Mike Matrigali failing consistently on one machine, 10.9, windows, weme - http://people.apache.org/~myrnavl/derby_test_results/v10_9/windows/testlog/weme6.2/1484050-derbyall_diff.txt *** Start: derbyrunjartest jdkWECE J2ME Foundation Specification v1.1 derbyall:derbytools 2013-05-17 23:02:07 *** 2 del Usage: java org.apache.derby.tools.ij [-p propertyfile] [inputfile] 2a2 Process exception: (2) The system cannot find the file specified. 4 del USAGE: java org.apache.derby.tools.sysinfo -cp [ [ embedded ][ server ][ client] [ tools ] [ anyClass.class ] ] 4a4 Process exception: (2) The system cannot find the file specified. 6 del USAGE: 7 del java org.apache.derby.tools.dblook -d sourceDBUrl [OPTIONS] 8 del where the source URL is the full URL, including the connection protocol 9 del and any connection attributes that might apply. For example, use 10 del 'jdbc:derby:myDB', or 'jdbc:derby://xxxFILTERED_HOSTNAMExxx:1527/myDB;user=usr;'. 11 del options include: 12 del -z schemaName to specify a schema to which the DDL generation 13 del should be limited. Only database objects with that schema will have 14 del their DDL generated. 15 del -t tableOne tableTwo ... to specify a list of tables for which 16 del the DDL will be generated; any tables not in the list will be ignored. 17 del -td value to specify what should be appended to the end 18 del of each DDL statement. 19 del This defaults to ';'. 20 del -noview to prevent the generation
[jira] [Commented] (DERBY-6251) nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified.
[ https://issues.apache.org/jira/browse/DERBY-6251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13679961#comment-13679961 ] ASF subversion and git services commented on DERBY-6251: Commit 1491619 from [~myrna] [ https://svn.apache.org/r1491619 ] DERBY-6251; nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified. backport of revision 1491566 from 10.9. nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified. Key: DERBY-6251 URL: https://issues.apache.org/jira/browse/DERBY-6251 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.6.2.3, 10.7.1.4, 10.9.2.2 Environment: Generating report for RunSuite derbyall j9_foundation11 j9 null null true -- Java Information -- Java Version:WECE J2ME Foundation Specification v1.1 Java Vendor: IBM Corporation Java home: C:\jartest\weme6.2 Java classpath: C:/jartest/jars/derbyrun.jar;C:/jartest/jars/derbyTesting.jar;c:/jartest/tools/java/jakarta-oro-2.0.8.jar;c:/jartest/junit/junit.jar; OS name: Windows Server 2008 OS architecture: x86 OS version: 6.1 build 7601 Service Pack 1 Java user name: cloudtest Java user home: C:\Users\cloudtest Java user dir: C:\jartest\JarResults.2013-05-17\weme6.2_derbyall java.specification.name: J2ME Foundation Specification java.specification.version: 1.1 java.runtime.version: 2.4 java.fullversion: IBM J9 2.4 Windows Server 2008 x86-32 (JIT enabled, AOT enabled) J9VM - 20080919_023055_lHdFGQ JIT - r9.weme62_20080724_2131 GC - 20080609_AA - Derby Information [C:\jartest\jars\derby.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbytools.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbynet.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbyclient.jar] 10.9.2.2 - (1484050) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [cs] version: 10.9.2.2 - (1484050) Found support for locale: [de_DE] version: 10.9.2.2 - (1484050) Found support for locale: [es] version: 10.9.2.2 - (1484050) Found support for locale: [fr] version: 10.9.2.2 - (1484050) Found support for locale: [hu] version: 10.9.2.2 - (1484050) Found support for locale: [it] version: 10.9.2.2 - (1484050) Found support for locale: [ja_JP] version: 10.9.2.2 - (1484050) Found support for locale: [ko_KR] version: 10.9.2.2 - (1484050) Found support for locale: [pl] version: 10.9.2.2 - (1484050) Found support for locale: [pt_BR] version: 10.9.2.2 - (1484050) Found support for locale: [ru] version: 10.9.2.2 - (1484050) Found support for locale: [zh_CN] version: 10.9.2.2 - (1484050) Found support for locale: [zh_TW] version: 10.9.2.2 - (1484050) Reporter: Mike Matrigali failing consistently on one machine, 10.9, windows, weme - http://people.apache.org/~myrnavl/derby_test_results/v10_9/windows/testlog/weme6.2/1484050-derbyall_diff.txt *** Start: derbyrunjartest jdkWECE J2ME Foundation Specification v1.1 derbyall:derbytools 2013-05-17 23:02:07 *** 2 del Usage: java org.apache.derby.tools.ij [-p propertyfile] [inputfile] 2a2 Process exception: (2) The system cannot find the file specified. 4 del USAGE: java org.apache.derby.tools.sysinfo -cp [ [ embedded ][ server ][ client] [ tools ] [ anyClass.class ] ] 4a4 Process exception: (2) The system cannot find the file specified. 6 del USAGE: 7 del java org.apache.derby.tools.dblook -d sourceDBUrl [OPTIONS] 8 del where the source URL is the full URL, including the connection protocol 9 del and any connection attributes that might apply. For example, use 10 del 'jdbc:derby:myDB', or 'jdbc:derby://xxxFILTERED_HOSTNAMExxx:1527/myDB;user=usr;'. 11 del options include: 12 del -z schemaName to specify a schema to which the DDL generation 13 del should be limited. Only database objects with that schema will have 14 del their DDL generated. 15 del -t tableOne tableTwo ... to specify a list of tables for which 16 del the DDL will be generated; any tables not in the list will be ignored. 17 del -td value to specify what should be appended to the end 18 del of each DDL statement. 19 del This defaults to ';'. 20 del -noview to prevent the
[jira] [Commented] (DERBY-6251) nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified.
[ https://issues.apache.org/jira/browse/DERBY-6251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13680004#comment-13680004 ] ASF subversion and git services commented on DERBY-6251: Commit 1491632 from [~myrna] [ https://svn.apache.org/r1491632 ] DERBY-6251; nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified. backport of revision 1491566 from 10.9. nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified. Key: DERBY-6251 URL: https://issues.apache.org/jira/browse/DERBY-6251 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.6.2.3, 10.7.1.4, 10.9.2.2 Environment: Generating report for RunSuite derbyall j9_foundation11 j9 null null true -- Java Information -- Java Version:WECE J2ME Foundation Specification v1.1 Java Vendor: IBM Corporation Java home: C:\jartest\weme6.2 Java classpath: C:/jartest/jars/derbyrun.jar;C:/jartest/jars/derbyTesting.jar;c:/jartest/tools/java/jakarta-oro-2.0.8.jar;c:/jartest/junit/junit.jar; OS name: Windows Server 2008 OS architecture: x86 OS version: 6.1 build 7601 Service Pack 1 Java user name: cloudtest Java user home: C:\Users\cloudtest Java user dir: C:\jartest\JarResults.2013-05-17\weme6.2_derbyall java.specification.name: J2ME Foundation Specification java.specification.version: 1.1 java.runtime.version: 2.4 java.fullversion: IBM J9 2.4 Windows Server 2008 x86-32 (JIT enabled, AOT enabled) J9VM - 20080919_023055_lHdFGQ JIT - r9.weme62_20080724_2131 GC - 20080609_AA - Derby Information [C:\jartest\jars\derby.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbytools.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbynet.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbyclient.jar] 10.9.2.2 - (1484050) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [cs] version: 10.9.2.2 - (1484050) Found support for locale: [de_DE] version: 10.9.2.2 - (1484050) Found support for locale: [es] version: 10.9.2.2 - (1484050) Found support for locale: [fr] version: 10.9.2.2 - (1484050) Found support for locale: [hu] version: 10.9.2.2 - (1484050) Found support for locale: [it] version: 10.9.2.2 - (1484050) Found support for locale: [ja_JP] version: 10.9.2.2 - (1484050) Found support for locale: [ko_KR] version: 10.9.2.2 - (1484050) Found support for locale: [pl] version: 10.9.2.2 - (1484050) Found support for locale: [pt_BR] version: 10.9.2.2 - (1484050) Found support for locale: [ru] version: 10.9.2.2 - (1484050) Found support for locale: [zh_CN] version: 10.9.2.2 - (1484050) Found support for locale: [zh_TW] version: 10.9.2.2 - (1484050) Reporter: Mike Matrigali failing consistently on one machine, 10.9, windows, weme - http://people.apache.org/~myrnavl/derby_test_results/v10_9/windows/testlog/weme6.2/1484050-derbyall_diff.txt *** Start: derbyrunjartest jdkWECE J2ME Foundation Specification v1.1 derbyall:derbytools 2013-05-17 23:02:07 *** 2 del Usage: java org.apache.derby.tools.ij [-p propertyfile] [inputfile] 2a2 Process exception: (2) The system cannot find the file specified. 4 del USAGE: java org.apache.derby.tools.sysinfo -cp [ [ embedded ][ server ][ client] [ tools ] [ anyClass.class ] ] 4a4 Process exception: (2) The system cannot find the file specified. 6 del USAGE: 7 del java org.apache.derby.tools.dblook -d sourceDBUrl [OPTIONS] 8 del where the source URL is the full URL, including the connection protocol 9 del and any connection attributes that might apply. For example, use 10 del 'jdbc:derby:myDB', or 'jdbc:derby://xxxFILTERED_HOSTNAMExxx:1527/myDB;user=usr;'. 11 del options include: 12 del -z schemaName to specify a schema to which the DDL generation 13 del should be limited. Only database objects with that schema will have 14 del their DDL generated. 15 del -t tableOne tableTwo ... to specify a list of tables for which 16 del the DDL will be generated; any tables not in the list will be ignored. 17 del -td value to specify what should be appended to the end 18 del of each DDL statement. 19 del This defaults to ';'. 20 del -noview to prevent the
[jira] [Commented] (DERBY-6251) nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified.
[ https://issues.apache.org/jira/browse/DERBY-6251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13680032#comment-13680032 ] ASF subversion and git services commented on DERBY-6251: Commit 1491636 from [~myrna] [ https://svn.apache.org/r1491636 ] DERBY-6251; nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified. backport of revision 1491566 from 10.9. nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified. Key: DERBY-6251 URL: https://issues.apache.org/jira/browse/DERBY-6251 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.6.2.3, 10.7.1.4, 10.9.2.2 Environment: Generating report for RunSuite derbyall j9_foundation11 j9 null null true -- Java Information -- Java Version:WECE J2ME Foundation Specification v1.1 Java Vendor: IBM Corporation Java home: C:\jartest\weme6.2 Java classpath: C:/jartest/jars/derbyrun.jar;C:/jartest/jars/derbyTesting.jar;c:/jartest/tools/java/jakarta-oro-2.0.8.jar;c:/jartest/junit/junit.jar; OS name: Windows Server 2008 OS architecture: x86 OS version: 6.1 build 7601 Service Pack 1 Java user name: cloudtest Java user home: C:\Users\cloudtest Java user dir: C:\jartest\JarResults.2013-05-17\weme6.2_derbyall java.specification.name: J2ME Foundation Specification java.specification.version: 1.1 java.runtime.version: 2.4 java.fullversion: IBM J9 2.4 Windows Server 2008 x86-32 (JIT enabled, AOT enabled) J9VM - 20080919_023055_lHdFGQ JIT - r9.weme62_20080724_2131 GC - 20080609_AA - Derby Information [C:\jartest\jars\derby.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbytools.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbynet.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbyclient.jar] 10.9.2.2 - (1484050) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [cs] version: 10.9.2.2 - (1484050) Found support for locale: [de_DE] version: 10.9.2.2 - (1484050) Found support for locale: [es] version: 10.9.2.2 - (1484050) Found support for locale: [fr] version: 10.9.2.2 - (1484050) Found support for locale: [hu] version: 10.9.2.2 - (1484050) Found support for locale: [it] version: 10.9.2.2 - (1484050) Found support for locale: [ja_JP] version: 10.9.2.2 - (1484050) Found support for locale: [ko_KR] version: 10.9.2.2 - (1484050) Found support for locale: [pl] version: 10.9.2.2 - (1484050) Found support for locale: [pt_BR] version: 10.9.2.2 - (1484050) Found support for locale: [ru] version: 10.9.2.2 - (1484050) Found support for locale: [zh_CN] version: 10.9.2.2 - (1484050) Found support for locale: [zh_TW] version: 10.9.2.2 - (1484050) Reporter: Mike Matrigali failing consistently on one machine, 10.9, windows, weme - http://people.apache.org/~myrnavl/derby_test_results/v10_9/windows/testlog/weme6.2/1484050-derbyall_diff.txt *** Start: derbyrunjartest jdkWECE J2ME Foundation Specification v1.1 derbyall:derbytools 2013-05-17 23:02:07 *** 2 del Usage: java org.apache.derby.tools.ij [-p propertyfile] [inputfile] 2a2 Process exception: (2) The system cannot find the file specified. 4 del USAGE: java org.apache.derby.tools.sysinfo -cp [ [ embedded ][ server ][ client] [ tools ] [ anyClass.class ] ] 4a4 Process exception: (2) The system cannot find the file specified. 6 del USAGE: 7 del java org.apache.derby.tools.dblook -d sourceDBUrl [OPTIONS] 8 del where the source URL is the full URL, including the connection protocol 9 del and any connection attributes that might apply. For example, use 10 del 'jdbc:derby:myDB', or 'jdbc:derby://xxxFILTERED_HOSTNAMExxx:1527/myDB;user=usr;'. 11 del options include: 12 del -z schemaName to specify a schema to which the DDL generation 13 del should be limited. Only database objects with that schema will have 14 del their DDL generated. 15 del -t tableOne tableTwo ... to specify a list of tables for which 16 del the DDL will be generated; any tables not in the list will be ignored. 17 del -td value to specify what should be appended to the end 18 del of each DDL statement. 19 del This defaults to ';'. 20 del -noview to prevent the
[jira] [Commented] (DERBY-6158) mailjdbc test in networkserver configuration does not perform compress correctly if server is started in a different directory
[ https://issues.apache.org/jira/browse/DERBY-6158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13680657#comment-13680657 ] ASF subversion and git services commented on DERBY-6158: Commit 1491950 from [~myrna] [ https://svn.apache.org/r1491950 ] DERBY-6158; mailjdbc test in networkserver configuration does not perform compress correctly if server is started in a different directory updating the README.txt file mailjdbc test in networkserver configuration does not perform compress correctly if server is started in a different directory -- Key: DERBY-6158 URL: https://issues.apache.org/jira/browse/DERBY-6158 Project: Derby Issue Type: Improvement Components: Test Reporter: Myrna van Lunteren Priority: Trivial The mailjdbc test uses a hardcoded string 'mailsdb' for the databasename in the compress call in org.apache.derbyTesting.system.mailjdbc.utils.DbTasks:compressTable. Thus, if one decides to start the network server in a different directory than the client, the compress calls fail. At least the README.txt should be modified to clarify this. Alternatively, the test could be modified to create the desired directory structure and start network server if needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6255) convert i18n/messageLocale.sql
[ https://issues.apache.org/jira/browse/DERBY-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681014#comment-13681014 ] ASF subversion and git services commented on DERBY-6255: Commit 1492088 from [~knutanders] [ https://svn.apache.org/r1492088 ] DERBY-6255: convert i18n/messageLocale.sql Reset the default locale when the test is done. convert i18n/messageLocale.sql -- Key: DERBY-6255 URL: https://issues.apache.org/jira/browse/DERBY-6255 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.10.1.1 Reporter: Kathey Marsden Attachments: derby-6255_diff.txt, reset-locale.diff Convert i18n/messageLocale.sql -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6114) OOME in XAMemTest.testDerby4137_TransactionTimeoutSpecifiedNotExceeded
[ https://issues.apache.org/jira/browse/DERBY-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681015#comment-13681015 ] ASF subversion and git services commented on DERBY-6114: Commit 1492094 from [~knutanders] [ https://svn.apache.org/r1492094 ] DERBY-6114: OOME in XAMemTest.testDerby4137_TransactionTimeoutSpecifiedNotExceeded Periodically run purge() on the cancellation timer to reclaim the space occupied by cancelled tasks. OOME in XAMemTest.testDerby4137_TransactionTimeoutSpecifiedNotExceeded -- Key: DERBY-6114 URL: https://issues.apache.org/jira/browse/DERBY-6114 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.2.2, 10.10.1.1 Environment: Derby head of 10.10 branch. ubuntu3 slave on builds.apache.org. Java SE 7u4, 64-bit. java.vendor=Oracle Corporation java.runtime.version=1.7.0_04-b20 os.name=Linux os.arch=amd64 os.version=3.2.0-38-generic Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: derby-6114-1a-purge.diff, derby.log, error-stacktrace.out Seen twice in a row in https://builds.apache.org/job/Derby-10.10-suites.All/ : junit-lowmem: [junit] Running org.apache.derbyTesting.functionTests.tests.memory._Suite [junit] Exception in thread DRDAConnThread_11 java.lang.OutOfMemoryError: GC overhead limit exceeded [junit] at java.util.Properties$LineReader.init(Properties.java:405) [junit] at java.util.Properties.load(Properties.java:341) [junit] at java.util.PropertyResourceBundle.init(PropertyResourceBundle.java:130) [junit] at java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2610) [junit] at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1436) [junit] at java.util.ResourceBundle.findBundle(ResourceBundle.java:1400) [junit] at java.util.ResourceBundle.findBundle(ResourceBundle.java:1354) [junit] at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1296) [junit] at java.util.ResourceBundle.getBundle(ResourceBundle.java:796) [junit] at org.apache.derby.iapi.services.i18n.MessageService.getBundleWithEnDefault(MessageService.java:318) [junit] at org.apache.derby.iapi.services.i18n.MessageService.getBundleForLocale(MessageService.java:53) [junit] at org.apache.derby.iapi.services.i18n.MessageService.getBundle(MessageService.java:302) [junit] at org.apache.derby.iapi.services.i18n.MessageService.getCompleteMessage(MessageService.java:97) [junit] at org.apache.derby.iapi.error.SQLWarningFactory.newSQLWarning(SQLWarningFactory.java:97) [junit] at org.apache.derby.iapi.error.SQLWarningFactory.newSQLWarning(SQLWarningFactory.java:50) [junit] at org.apache.derby.iapi.jdbc.BrokeredConnection.statementHoldabilityCheck(BrokeredConnection.java:736) [junit] at org.apache.derby.iapi.jdbc.BrokeredConnection.prepareStatement(BrokeredConnection.java:690) [junit] at org.apache.derby.impl.drda.DRDAStatement.prepare(DRDAStatement.java:669) [junit] at org.apache.derby.impl.drda.DRDAStatement.explicitPrepare(DRDAStatement.java:630) [junit] at org.apache.derby.impl.drda.DRDAConnThread.parsePRPSQLSTT(DRDAConnThread.java:3912) [junit] at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:811) [junit] at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:295) [junit] Tests run: 67, Failures: 0, Errors: 1, Time elapsed: 1,571.059 sec [junit] Test org.apache.derbyTesting.functionTests.tests.memory._Suite FAILED -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6213) Deprecate support for Java 5 and CDC
[ https://issues.apache.org/jira/browse/DERBY-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681044#comment-13681044 ] ASF subversion and git services commented on DERBY-6213: Commit 1492111 from [~knutanders] [ https://svn.apache.org/r1492111 ] DERBY-6213: Deprecate support for Java 5 and CDC - Remove checks for the JVMInfo.J2ME constant - Move functionality from DirStorageFactory4 to the base class Deprecate support for Java 5 and CDC Key: DERBY-6213 URL: https://issues.apache.org/jira/browse/DERBY-6213 Project: Derby Issue Type: Improvement Components: Build tools, Documentation, Javadoc Affects Versions: 10.11.0.0 Reporter: Rick Hillegas Attachments: buildbreak2-datasource.diff, buildbreak.diff, client.diff, deprecate-datasources.diff, derby-6213-01-aa-collapsePublishedAPI.diff, derby-6213-02-aa-org.apache.derby.vti.diff, derby-6213-03-aa-misc.diff, derby-6213-03-ab-misc.diff, derby-6213-04-aa-vtiPackageOnJava7.diff, derby-6213-05-ab-misc2.diff, derby-6213-06-aa-convertProductToJava6.diff, derby-6213-06-ab-removeCDC.diff, derby-6213-07-aa-restOfProductExceptJDBC.diff, derby-6213-08-ab-jdbc.diff, derby-6213-09-ab-lint1.diff, derby-6213-10-aa-lint2-implServices.diff, derby-6213-11-aa-lint3-implStore.diff, derby-6213-12-aa-lint4-implSqlCatalog-implSqlDepend.diff, derby-6213-13-aa-lint4-implSqlConn.diff, derby-6213-14-aa-lint6-implSqlCompile-implSqlExecute.diff, derby-6213-15-aa-lint7.diff, derby-6213-16-aa-lint8.diff, derby-6213-17-aa-lint9.diff, derby-6213-17-ab-lint9.diff, derby-6213-18-aa-collapseEmbeddedDataSources.diff, derby-6213-20-aa-remove.java15.compile.classpath.diff, derby-6213-21-aa-felixLint.diff, derby-6213-22-aa-remove1.4and1.5sourceAndTargetLevels.diff, derby-6213-23-aa-removeSimpleMobileApp.diff, derby-6213-24-aa-makeBasicConnectionPoolDataSource40public.diff, descriptor-lists.diff, jvminfo-j2me.diff, releaseNote.html, releaseNote.html, revive-sqlxmlutil-target.diff, simplify-with-java5.diff, simplify-with-java5-v2.diff, testcode.diff The developer community has approved the proposal to sunset support for Java 5 and CDC: http://apache-database.10148.n7.nabble.com/VOTE-Sunsetting-support-for-Java-5-and-CDC-td129832.html#a129925 This issue tracks a number of tasks needed to implement this proposal: I) Remove build support for Java 5 and CDC. II) Purge user doc references to Java 5, CDC, and the JDBC 4 DataSources. III) Remove the JDBC 4 version of the public api from the published javadoc. The recently introduced CP2 DataSources would need to migrate to the JDBC 3 version of the published javadoc. The JDBC 4 versions of the DataSources would still exist, but they would be vacuous extensions of their JDBC 3 counterparts. IV) On the wiki, document our expectation that maintenance releases will support the same platforms as the original feature release cut from their branch. V) Decide what to do with the SimpleMobileApp. Probably we want to just remove this demo since its purpose is to show how to run Derby on the deprecated CDC platform. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6258) Restrict permissions on BACKUP.HISTORY
[ https://issues.apache.org/jira/browse/DERBY-6258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681043#comment-13681043 ] ASF subversion and git services commented on DERBY-6258: Commit 1492110 from [~knutanders] [ https://svn.apache.org/r1492110 ] DERBY-6258: Restrict permissions on BACKUP.HISTORY Restrict permissions on BACKUP.HISTORY -- Key: DERBY-6258 URL: https://issues.apache.org/jira/browse/DERBY-6258 Project: Derby Issue Type: Improvement Components: Store Affects Versions: 10.9.1.0, 10.10.1.1 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Attachments: derby-6258-01-a.diff DirFile4.getOutputStream(boolean) does not restrict the file permissions on the file if it ends up creating a new file. This method is only used for writing to BACKUP.HISTORY during backup. The BACKUP.HISTORY file in the backup does have restricted file permissions, it is only the file in the original database that is created with less restrictive permissions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6213) Deprecate support for Java 5 and CDC
[ https://issues.apache.org/jira/browse/DERBY-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681047#comment-13681047 ] ASF subversion and git services commented on DERBY-6213: Commit 1492116 from [~knutanders] [ https://svn.apache.org/r1492116 ] DERBY-6213: Deprecate support for Java 5 and CDC Remove constants for no longer supported Java versions in JVMInfo. Remove checks for Java version where same action would be taken for all supported Java versions. Deprecate support for Java 5 and CDC Key: DERBY-6213 URL: https://issues.apache.org/jira/browse/DERBY-6213 Project: Derby Issue Type: Improvement Components: Build tools, Documentation, Javadoc Affects Versions: 10.11.0.0 Reporter: Rick Hillegas Attachments: buildbreak2-datasource.diff, buildbreak.diff, client.diff, deprecate-datasources.diff, derby-6213-01-aa-collapsePublishedAPI.diff, derby-6213-02-aa-org.apache.derby.vti.diff, derby-6213-03-aa-misc.diff, derby-6213-03-ab-misc.diff, derby-6213-04-aa-vtiPackageOnJava7.diff, derby-6213-05-ab-misc2.diff, derby-6213-06-aa-convertProductToJava6.diff, derby-6213-06-ab-removeCDC.diff, derby-6213-07-aa-restOfProductExceptJDBC.diff, derby-6213-08-ab-jdbc.diff, derby-6213-09-ab-lint1.diff, derby-6213-10-aa-lint2-implServices.diff, derby-6213-11-aa-lint3-implStore.diff, derby-6213-12-aa-lint4-implSqlCatalog-implSqlDepend.diff, derby-6213-13-aa-lint4-implSqlConn.diff, derby-6213-14-aa-lint6-implSqlCompile-implSqlExecute.diff, derby-6213-15-aa-lint7.diff, derby-6213-16-aa-lint8.diff, derby-6213-17-aa-lint9.diff, derby-6213-17-ab-lint9.diff, derby-6213-18-aa-collapseEmbeddedDataSources.diff, derby-6213-20-aa-remove.java15.compile.classpath.diff, derby-6213-21-aa-felixLint.diff, derby-6213-22-aa-remove1.4and1.5sourceAndTargetLevels.diff, derby-6213-23-aa-removeSimpleMobileApp.diff, derby-6213-24-aa-makeBasicConnectionPoolDataSource40public.diff, descriptor-lists.diff, jvminfo-j2me.diff, jvminfo-oldconstants.diff, releaseNote.html, releaseNote.html, revive-sqlxmlutil-target.diff, simplify-with-java5.diff, simplify-with-java5-v2.diff, testcode.diff The developer community has approved the proposal to sunset support for Java 5 and CDC: http://apache-database.10148.n7.nabble.com/VOTE-Sunsetting-support-for-Java-5-and-CDC-td129832.html#a129925 This issue tracks a number of tasks needed to implement this proposal: I) Remove build support for Java 5 and CDC. II) Purge user doc references to Java 5, CDC, and the JDBC 4 DataSources. III) Remove the JDBC 4 version of the public api from the published javadoc. The recently introduced CP2 DataSources would need to migrate to the JDBC 3 version of the published javadoc. The JDBC 4 versions of the DataSources would still exist, but they would be vacuous extensions of their JDBC 3 counterparts. IV) On the wiki, document our expectation that maintenance releases will support the same platforms as the original feature release cut from their branch. V) Decide what to do with the SimpleMobileApp. Probably we want to just remove this demo since its purpose is to show how to run Derby on the deprecated CDC platform. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6114) OOME in XAMemTest.testDerby4137_TransactionTimeoutSpecifiedNotExceeded
[ https://issues.apache.org/jira/browse/DERBY-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681077#comment-13681077 ] ASF subversion and git services commented on DERBY-6114: Commit 1492127 from [~knutanders] [ https://svn.apache.org/r1492127 ] DERBY-6114: OOME in XAMemTest.testDerby4137_TransactionTimeoutSpecifiedNotExceeded Merged revision 1492094 from trunk and manually resolved conflicts. OOME in XAMemTest.testDerby4137_TransactionTimeoutSpecifiedNotExceeded -- Key: DERBY-6114 URL: https://issues.apache.org/jira/browse/DERBY-6114 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.2.2, 10.10.1.1 Environment: Derby head of 10.10 branch. ubuntu3 slave on builds.apache.org. Java SE 7u4, 64-bit. java.vendor=Oracle Corporation java.runtime.version=1.7.0_04-b20 os.name=Linux os.arch=amd64 os.version=3.2.0-38-generic Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: backport-10.10.diff, derby-6114-1a-purge.diff, derby.log, error-stacktrace.out Seen twice in a row in https://builds.apache.org/job/Derby-10.10-suites.All/ : junit-lowmem: [junit] Running org.apache.derbyTesting.functionTests.tests.memory._Suite [junit] Exception in thread DRDAConnThread_11 java.lang.OutOfMemoryError: GC overhead limit exceeded [junit] at java.util.Properties$LineReader.init(Properties.java:405) [junit] at java.util.Properties.load(Properties.java:341) [junit] at java.util.PropertyResourceBundle.init(PropertyResourceBundle.java:130) [junit] at java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2610) [junit] at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1436) [junit] at java.util.ResourceBundle.findBundle(ResourceBundle.java:1400) [junit] at java.util.ResourceBundle.findBundle(ResourceBundle.java:1354) [junit] at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1296) [junit] at java.util.ResourceBundle.getBundle(ResourceBundle.java:796) [junit] at org.apache.derby.iapi.services.i18n.MessageService.getBundleWithEnDefault(MessageService.java:318) [junit] at org.apache.derby.iapi.services.i18n.MessageService.getBundleForLocale(MessageService.java:53) [junit] at org.apache.derby.iapi.services.i18n.MessageService.getBundle(MessageService.java:302) [junit] at org.apache.derby.iapi.services.i18n.MessageService.getCompleteMessage(MessageService.java:97) [junit] at org.apache.derby.iapi.error.SQLWarningFactory.newSQLWarning(SQLWarningFactory.java:97) [junit] at org.apache.derby.iapi.error.SQLWarningFactory.newSQLWarning(SQLWarningFactory.java:50) [junit] at org.apache.derby.iapi.jdbc.BrokeredConnection.statementHoldabilityCheck(BrokeredConnection.java:736) [junit] at org.apache.derby.iapi.jdbc.BrokeredConnection.prepareStatement(BrokeredConnection.java:690) [junit] at org.apache.derby.impl.drda.DRDAStatement.prepare(DRDAStatement.java:669) [junit] at org.apache.derby.impl.drda.DRDAStatement.explicitPrepare(DRDAStatement.java:630) [junit] at org.apache.derby.impl.drda.DRDAConnThread.parsePRPSQLSTT(DRDAConnThread.java:3912) [junit] at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:811) [junit] at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:295) [junit] Tests run: 67, Failures: 0, Errors: 1, Time elapsed: 1,571.059 sec [junit] Test org.apache.derbyTesting.functionTests.tests.memory._Suite FAILED -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6211) Make Optimizer trace logic pluggable.
[ https://issues.apache.org/jira/browse/DERBY-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681526#comment-13681526 ] ASF subversion and git services commented on DERBY-6211: Commit 1492378 from [~rhillegas] [ https://svn.apache.org/r1492378 ] DERBY-6211: Commit derby-6211-06-ab-packageProtect-XMLOptTrace.diff, reducing the visibility of XMLOptTrace. Make Optimizer trace logic pluggable. - Key: DERBY-6211 URL: https://issues.apache.org/jira/browse/DERBY-6211 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.11.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: derby-6211-01-aa-createPlugin.diff, derby-6211-02-aa-cleanup.diff, derby-6211-02-ab-cleanup.diff, derby-6211-03-aa-customTracer.diff, derby-6211-04-aa-moveOptimizerTracerToEngineJar.diff, derby-6211-05-aa-xmlOptimizerTracer.diff, derby-6211-06-ab-packageProtect-XMLOptTrace.diff Right now the trace logic in the optimizer is hard-coded to produce a stream of diagnostics. It would be good to be able to plug alternative trace logic into the optimizer. This would make the following possible: 1) Plug in trace logic which produces formats which are easier to study and which can be analyzed mechanically. E.g., xml formatted output. 2) Plug in trace logic which can be used during unit testing to verify that the optimizer has picked the right plan. Over time this might make it easier to migrate canon-based tests to assertion-based tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-4035) i18n tests fail with Lexical error on z/os
[ https://issues.apache.org/jira/browse/DERBY-4035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681545#comment-13681545 ] ASF subversion and git services commented on DERBY-4035: Commit 1492393 from [~kmarsden] [ https://svn.apache.org/r1492393 ] DERBY-4035 i18n tests fail with Lexical error on z/os Complete conversion of i18nTest suite. I18NImportExport change to ScriptTestCase iepnegativetests_ES changed to extend tools/ImportExportProcedureTest which has conversion for iepnegativetests i18n tests fail with Lexical error on z/os --- Key: DERBY-4035 URL: https://issues.apache.org/jira/browse/DERBY-4035 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.3.3.0, 10.5.1.1 Environment: java version 1.6.0 Java(TM) SE Runtime Environment (build pmz6460sr3-20081108_01(SR3)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 z/OS s390x-64 jvmmz6460-20081107_25433 (JIT enabled, AOT enabled) J9VM - 20081105_025433_BHdSMr JIT - r9_20081031_1330 GC - 20081027_AB) JCL - 20081106_01 $ Reporter: Kathey Marsden Assignee: Kathey Marsden Labels: derby_triage10_5_2 Attachments: derby-4035_I18NImportExport_diff.txt, derby-4035_I18NImportExport_ieptestsnegative_diff.txt On z/os the following tests fail with a Lexical error e.g. ERROR 42X02: Lexical error at line 1, column 1. Encountered: ` (96), after : . There also seems to be some garbage in the output. The tests that fail with these errors are: derbyall/derbyall.fail:i18n/JapanCodeConversion.sql derbyall/derbyall.fail:i18n/UnicodeEscape_JP.sql derbyall/derbyall.fail:i18n/I18NImportExport.sql derbyall/derbyall.fail:i18n/urlLocale.sql derbyall/derbyall.fail:i18n/messageLocale.sql derbyall/derbyall.fail:i18n/caseI_tr_TR.sql derbyall/derbyall.fail:i18n/iepnegativetests_ES.sql The error I think is coming from ij, it is not in the derby.log and there is not a stack trace anywhere. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-1984) Re-factor JDBC classes to remove support for JDBC 2
[ https://issues.apache.org/jira/browse/DERBY-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13681979#comment-13681979 ] ASF subversion and git services commented on DERBY-1984: Commit 1492544 from [~knutanders] [ https://svn.apache.org/r1492544 ] DERBY-1984: Re-factor JDBC classes to remove support for JDBC 2 Collapsed sub-classes of EmbedStatement by moving functionality to the base class and removing specialized sub-classes for JDBC 2.0, JDBC 3.0 and JDBC 4.0. Re-factor JDBC classes to remove support for JDBC 2 --- Key: DERBY-1984 URL: https://issues.apache.org/jira/browse/DERBY-1984 Project: Derby Issue Type: Sub-task Components: JDBC Reporter: Daniel John Debrunner Attachments: derby-1984-01-a.diff, derby-1984-01-b.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6259) Collapse the level 2 optimizer into its parent module.
[ https://issues.apache.org/jira/browse/DERBY-6259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682181#comment-13682181 ] ASF subversion and git services commented on DERBY-6259: Commit 1492641 from [~rhillegas] [ https://svn.apache.org/r1492641 ] DERBY-6259: Commit derby-6259-01-aa-collapseOptimizers.diff, eliminating the level 2 optimizer. Collapse the level 2 optimizer into its parent module. -- Key: DERBY-6259 URL: https://issues.apache.org/jira/browse/DERBY-6259 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.11.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: derby-6259-01-aa-collapseOptimizers.diff Right now there are 2 optimizer implementations, only one of which is ever loaded. The other implementation was disabled by the following comment in modules.properties: # use level1 optimizer for small configurations # # can't do this in the codeline because with 2 implementations, it is entirely # by chance which get picked. So we may be running with different modules # depending on which jdk # # to be resolve by Siuling and Dan # #derby.module.optimizerSmall=org.apache.derby.impl.sql.compile.OptimizerFactoryImpl #cloudscape.config.optimizerSmall=cloud,cloudtarget Since we have deprecated support for the small CDC configuration, I don't think that we need further resolution by Siuling and Dan. Collapsing the two optimizers together should slightly reduce our static footprint. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-4035) i18n tests fail with Lexical error on z/os
[ https://issues.apache.org/jira/browse/DERBY-4035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682204#comment-13682204 ] ASF subversion and git services commented on DERBY-4035: Commit 1492652 from [~kmarsden] [ https://svn.apache.org/r1492652 ] DERBY-4035 i18n tests fail with Lexical error on z/os merge from trunk ... DERBY-6244 convert i18n/caseI_tr_TR.sql to JUnit 1489924 DERBY-6246 convert i18n/urlLocale.sql to JUnit 1490716 1491364 DERBY-6255 convert i18n/messageLocale.sql to JUnit 1491542 1491590 1492088 convert ieptestsnegative_ES and I18NImportExport 1492393 i18n tests fail with Lexical error on z/os --- Key: DERBY-4035 URL: https://issues.apache.org/jira/browse/DERBY-4035 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.3.3.0, 10.5.1.1 Environment: java version 1.6.0 Java(TM) SE Runtime Environment (build pmz6460sr3-20081108_01(SR3)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 z/OS s390x-64 jvmmz6460-20081107_25433 (JIT enabled, AOT enabled) J9VM - 20081105_025433_BHdSMr JIT - r9_20081031_1330 GC - 20081027_AB) JCL - 20081106_01 $ Reporter: Kathey Marsden Assignee: Kathey Marsden Labels: derby_triage10_5_2 Attachments: derby-4035_I18NImportExport_diff.txt, derby-4035_I18NImportExport_ieptestsnegative_diff.txt On z/os the following tests fail with a Lexical error e.g. ERROR 42X02: Lexical error at line 1, column 1. Encountered: ` (96), after : . There also seems to be some garbage in the output. The tests that fail with these errors are: derbyall/derbyall.fail:i18n/JapanCodeConversion.sql derbyall/derbyall.fail:i18n/UnicodeEscape_JP.sql derbyall/derbyall.fail:i18n/I18NImportExport.sql derbyall/derbyall.fail:i18n/urlLocale.sql derbyall/derbyall.fail:i18n/messageLocale.sql derbyall/derbyall.fail:i18n/caseI_tr_TR.sql derbyall/derbyall.fail:i18n/iepnegativetests_ES.sql The error I think is coming from ij, it is not in the derby.log and there is not a stack trace anywhere. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6246) convert i18n/urlLocale.sql to JUnit
[ https://issues.apache.org/jira/browse/DERBY-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682206#comment-13682206 ] ASF subversion and git services commented on DERBY-6246: Commit 1492652 from [~kmarsden] [ https://svn.apache.org/r1492652 ] DERBY-4035 i18n tests fail with Lexical error on z/os merge from trunk ... DERBY-6244 convert i18n/caseI_tr_TR.sql to JUnit 1489924 DERBY-6246 convert i18n/urlLocale.sql to JUnit 1490716 1491364 DERBY-6255 convert i18n/messageLocale.sql to JUnit 1491542 1491590 1492088 convert ieptestsnegative_ES and I18NImportExport 1492393 convert i18n/urlLocale.sql to JUnit Key: DERBY-6246 URL: https://issues.apache.org/jira/browse/DERBY-6246 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.10.1.1 Reporter: Kathey Marsden Assignee: Kathey Marsden Fix For: 10.11.0.0 Attachments: derby-6246_diff2.txt, derby-6246_diff.txt Convert i18n/urlLocale.sql to JUnit so that it passes on z/os. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6255) convert i18n/messageLocale.sql
[ https://issues.apache.org/jira/browse/DERBY-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682207#comment-13682207 ] ASF subversion and git services commented on DERBY-6255: Commit 1492652 from [~kmarsden] [ https://svn.apache.org/r1492652 ] DERBY-4035 i18n tests fail with Lexical error on z/os merge from trunk ... DERBY-6244 convert i18n/caseI_tr_TR.sql to JUnit 1489924 DERBY-6246 convert i18n/urlLocale.sql to JUnit 1490716 1491364 DERBY-6255 convert i18n/messageLocale.sql to JUnit 1491542 1491590 1492088 convert ieptestsnegative_ES and I18NImportExport 1492393 convert i18n/messageLocale.sql -- Key: DERBY-6255 URL: https://issues.apache.org/jira/browse/DERBY-6255 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.10.1.1 Reporter: Kathey Marsden Attachments: derby-6255_diff.txt, reset-locale.diff Convert i18n/messageLocale.sql -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6244) convert i18n/caseI_tr_TR.sql to JUnit
[ https://issues.apache.org/jira/browse/DERBY-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682205#comment-13682205 ] ASF subversion and git services commented on DERBY-6244: Commit 1492652 from [~kmarsden] [ https://svn.apache.org/r1492652 ] DERBY-4035 i18n tests fail with Lexical error on z/os merge from trunk ... DERBY-6244 convert i18n/caseI_tr_TR.sql to JUnit 1489924 DERBY-6246 convert i18n/urlLocale.sql to JUnit 1490716 1491364 DERBY-6255 convert i18n/messageLocale.sql to JUnit 1491542 1491590 1492088 convert ieptestsnegative_ES and I18NImportExport 1492393 convert i18n/caseI_tr_TR.sql to JUnit - Key: DERBY-6244 URL: https://issues.apache.org/jira/browse/DERBY-6244 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.10.1.1 Reporter: Kathey Marsden Assignee: Kathey Marsden Fix For: 10.11.0.0 Attachments: derby-6244_diff.txt Convert :i18n/caseI_tr_TR.sql to resolve i18n failures on z/OS (DERBY-4035). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6259) Collapse the level 2 optimizer into its parent module.
[ https://issues.apache.org/jira/browse/DERBY-6259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682428#comment-13682428 ] ASF subversion and git services commented on DERBY-6259: Commit 1492766 from [~rhillegas] [ https://svn.apache.org/r1492766 ] DERBY-6259: Make optimizer fields private: tests passed cleanly on derby-6259-02-aa-increasePrivacy.diff. Collapse the level 2 optimizer into its parent module. -- Key: DERBY-6259 URL: https://issues.apache.org/jira/browse/DERBY-6259 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.11.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: derby-6259-01-aa-collapseOptimizers.diff, derby-6259-02-aa-increasePrivacy.diff Right now there are 2 optimizer implementations, only one of which is ever loaded. The other implementation was disabled by the following comment in modules.properties: # use level1 optimizer for small configurations # # can't do this in the codeline because with 2 implementations, it is entirely # by chance which get picked. So we may be running with different modules # depending on which jdk # # to be resolve by Siuling and Dan # #derby.module.optimizerSmall=org.apache.derby.impl.sql.compile.OptimizerFactoryImpl #cloudscape.config.optimizerSmall=cloud,cloudtarget Since we have deprecated support for the small CDC configuration, I don't think that we need further resolution by Siuling and Dan. Collapsing the two optimizers together should slightly reduce our static footprint. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6261) test getCurConnJdbc20.sql is no longer useful and can be removed
[ https://issues.apache.org/jira/browse/DERBY-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682758#comment-13682758 ] ASF subversion and git services commented on DERBY-6261: Commit 1492870 from [~myrna] [ https://svn.apache.org/r1492870 ] DERBY-6261; test getCurConnJdbc20.sql is no longer useful and can be removed. test getCurConnJdbc20.sql is no longer useful and can be removed Key: DERBY-6261 URL: https://issues.apache.org/jira/browse/DERBY-6261 Project: Derby Issue Type: Improvement Components: Test Affects Versions: 10.11.0.0 Reporter: Myrna van Lunteren Assignee: Myrna van Lunteren Priority: Trivial The old harness style test jdbcapi/getCurConnJdbc20.sql is the last test remaining in the jdbc20 suite. It runs with jdk12test=true, meaning with any jvm higher than 1.1. It creates a table, creates a procedure and executes it, then drops the table and procedure. The comment before running the function says: -- now lets try a variety of errors However, the function is util.Jdbc20Test.newToJdbc20Method, but all this does is: Statement stmt = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY); I don't see this doing anything more useful. Perhaps more interesting things were planned but never implemented, this type of statement is also created and tested in jdbcapi.ResultSetJdbc30Test, and we don't support anything older than 1.6 now anymore, so this test can just go. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-4785) Remove JCC tests and references to JCC in test code
[ https://issues.apache.org/jira/browse/DERBY-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682840#comment-13682840 ] ASF subversion and git services commented on DERBY-4785: Commit 1492887 from [~myrna] [ https://svn.apache.org/r1492887 ] DERBY-4785; Remove JCC tests and references to JCC in test code Removing the last few files from the suites dir and the entire master/DerbyNet directory. Remove JCC tests and references to JCC in test code --- Key: DERBY-4785 URL: https://issues.apache.org/jira/browse/DERBY-4785 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.5.1.1, 10.6.1.0 Reporter: Kathey Marsden Assignee: Jayaram Subramanian Priority: Minor Attachments: d4785-compat-1a.diff, diff-jan172012.diff, Feb142012.diff, Feb142012.stat, JCC_Removal_DONOTCOMMIT_Dec29.txt, JCCRemoval_Feb182011.txt, JCCRemoval_Jan112011.txt, jccremoval_Jan27.txt, JCCRemovalStat_Feb182011.txt, jccremoval_stats_Jan27.txt, stat_Dec29_JCC.txt, stat-jan172012.stat, Stat_JCCRemoval_Jan112011.txt I received a request to remove JCC testing from the derby suite. The user had a very old jcc version in their classpath 2.4 and 10.5 tests were failing with: com.ibm.db2.jcc.c.SqlException: DB2 SQL error: SQLCODE: -1, SQLSTATE: XJ040, SQLERRMC: Failed to start database '/results/axxon/58712/laka10a-derby-m101-20100830-003810/derbyall/derbynetmats/DerbyNet/derbynetmats/dblook_test_net_territory//wombat', see the next exception for details.::SQLSTATE: XJ001Java exception: 'Access denied (java.util.PropertyPermission com.ibm.crypto.provider.FIPSMODE read): java.security.AccessControlException'. at com.ibm.db2.jcc.c.o.a(o.java:3219) at com.ibm.db2.jcc.a.cb.q(cb.java:653) at com.ibm.db2.jcc.a.cb.p(cb.java:541) at com.ibm.db2.jcc.a.cb.l(cb.java:363) at com.ibm.db2.jcc.a.cb.d(cb.java:145) at com.ibm.db2.jcc.a.b.Sb(b.java:1274) at com.ibm.db2.jcc.a.b.a(b.java:1166) at com.ibm.db2.jcc.a.b.q(b.java:934) at com.ibm.db2.jcc.a.b.a(b.java:702) at com.ibm.db2.jcc.a.b.(b.java:305) at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:162) at java.sql.DriverManager.getConnection(DriverManager.java:322) at java.sql.DriverManager.getConnection(DriverManager.java:273) at org.apache.derby.tools.dblook.go(Unknown Source) at org.apache.derby.tools.dblook.(Unknown Source) at org.apache.derbyTesting.functionTests.tests.tools.dblook_test.lookThree(dblook_test.java:417) at org.apache.derbyTesting.functionTests.tests.tools.dblook_test.runTest(dblook_test.java:283) at org.apache.derbyTesting.functionTests.tests.derbynet.dblook_test_net_territory.doTest(dblook_test_net_territory.java:65) at org.apache.derbyTesting.functionTests.tests.derbynet.dblook_test_net_territory.main(dblook_test_net_territory.java:41) Now that I look at it more closely, their actual problem might be on the server side and JCC just reporting it but good to get the JCC tests out of the mix when people accidentally have it in their classpath anyway. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6251) nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified.
[ https://issues.apache.org/jira/browse/DERBY-6251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13682920#comment-13682920 ] ASF subversion and git services commented on DERBY-6251: Commit 1492910 from [~myrna] [ https://svn.apache.org/r1492910 ] DERBY-6251; nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified. marking JapanCodeConversion to not run with j9foundation with 10.1 for similar reasons. nightly regression test failure on weme, derbyrunjartest failing with: Process exception: (2) The system cannot find the file specified. Key: DERBY-6251 URL: https://issues.apache.org/jira/browse/DERBY-6251 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.6.2.3, 10.7.1.4, 10.9.2.2 Environment: Generating report for RunSuite derbyall j9_foundation11 j9 null null true -- Java Information -- Java Version:WECE J2ME Foundation Specification v1.1 Java Vendor: IBM Corporation Java home: C:\jartest\weme6.2 Java classpath: C:/jartest/jars/derbyrun.jar;C:/jartest/jars/derbyTesting.jar;c:/jartest/tools/java/jakarta-oro-2.0.8.jar;c:/jartest/junit/junit.jar; OS name: Windows Server 2008 OS architecture: x86 OS version: 6.1 build 7601 Service Pack 1 Java user name: cloudtest Java user home: C:\Users\cloudtest Java user dir: C:\jartest\JarResults.2013-05-17\weme6.2_derbyall java.specification.name: J2ME Foundation Specification java.specification.version: 1.1 java.runtime.version: 2.4 java.fullversion: IBM J9 2.4 Windows Server 2008 x86-32 (JIT enabled, AOT enabled) J9VM - 20080919_023055_lHdFGQ JIT - r9.weme62_20080724_2131 GC - 20080609_AA - Derby Information [C:\jartest\jars\derby.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbytools.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbynet.jar] 10.9.2.2 - (1484050) [C:\jartest\jars\derbyclient.jar] 10.9.2.2 - (1484050) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [cs] version: 10.9.2.2 - (1484050) Found support for locale: [de_DE] version: 10.9.2.2 - (1484050) Found support for locale: [es] version: 10.9.2.2 - (1484050) Found support for locale: [fr] version: 10.9.2.2 - (1484050) Found support for locale: [hu] version: 10.9.2.2 - (1484050) Found support for locale: [it] version: 10.9.2.2 - (1484050) Found support for locale: [ja_JP] version: 10.9.2.2 - (1484050) Found support for locale: [ko_KR] version: 10.9.2.2 - (1484050) Found support for locale: [pl] version: 10.9.2.2 - (1484050) Found support for locale: [pt_BR] version: 10.9.2.2 - (1484050) Found support for locale: [ru] version: 10.9.2.2 - (1484050) Found support for locale: [zh_CN] version: 10.9.2.2 - (1484050) Found support for locale: [zh_TW] version: 10.9.2.2 - (1484050) Reporter: Mike Matrigali Assignee: Myrna van Lunteren Fix For: 10.3.3.1, 10.4.2.1, 10.5.3.2, 10.6.2.3, 10.7.1.4, 10.8.3.1, 10.9.2.2 failing consistently on one machine, 10.9, windows, weme - http://people.apache.org/~myrnavl/derby_test_results/v10_9/windows/testlog/weme6.2/1484050-derbyall_diff.txt *** Start: derbyrunjartest jdkWECE J2ME Foundation Specification v1.1 derbyall:derbytools 2013-05-17 23:02:07 *** 2 del Usage: java org.apache.derby.tools.ij [-p propertyfile] [inputfile] 2a2 Process exception: (2) The system cannot find the file specified. 4 del USAGE: java org.apache.derby.tools.sysinfo -cp [ [ embedded ][ server ][ client] [ tools ] [ anyClass.class ] ] 4a4 Process exception: (2) The system cannot find the file specified. 6 del USAGE: 7 del java org.apache.derby.tools.dblook -d sourceDBUrl [OPTIONS] 8 del where the source URL is the full URL, including the connection protocol 9 del and any connection attributes that might apply. For example, use 10 del 'jdbc:derby:myDB', or 'jdbc:derby://xxxFILTERED_HOSTNAMExxx:1527/myDB;user=usr;'. 11 del options include: 12 del -z schemaName to specify a schema to which the DDL generation 13 del should be limited. Only database objects with that schema will have 14 del their DDL generated. 15 del -t tableOne tableTwo ... to specify a list of tables for which 16 del the DDL will be generated; any tables not in the list will be ignored. 17 del
[jira] [Commented] (DERBY-6224) Many test failures on latest JDK 8 EA build because of missing SQLPermission
[ https://issues.apache.org/jira/browse/DERBY-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683365#comment-13683365 ] ASF subversion and git services commented on DERBY-6224: Commit 1493077 from [~knutanders] [ https://svn.apache.org/r1493077 ] DERBY-6224: Many test failures on latest JDK 8 EA build because of missing SQLPermission Continue shutdown if deregistering fails, and report the failure in derby.log. Many test failures on latest JDK 8 EA build because of missing SQLPermission Key: DERBY-6224 URL: https://issues.apache.org/jira/browse/DERBY-6224 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.11.0.0 Environment: java version 1.8.0-ea Java(TM) SE Runtime Environment (build 1.8.0-ea-b89) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b31, mixed mode) Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.9.2.2, 10.10.1.2, 10.11.0.0 Attachments: derby-6224-01-a.diff, derby-6224-01-b.diff, derby-6224-02-a.diff, derby-6224-02-b-with-test.diff, releaseNote.html With the latest EA build of JDK 8 (build 1.8.0-ea-b89), I see many failures in suites.All. For example: 1) testStartNetworkServerFalse(org.apache.derbyTesting.functionTests.tests.derbynet.DerbyNetAutoStartTest)java.security.AccessControlException: access denied (java.sql.SQLPermission deregisterDriver) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:364) at java.security.AccessController.checkPermission(AccessController.java:562) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.sql.DriverManager.deregisterDriver(DriverManager.java:399) at org.apache.derby.jdbc.AutoloadedDriver.unregisterDriverModule(AutoloadedDriver.java:263) at org.apache.derby.jdbc.Driver20.stop(Driver20.java:105) at org.apache.derby.impl.services.monitor.TopService.stop(TopService.java:443) at org.apache.derby.impl.services.monitor.TopService.shutdown(TopService.java:394) at org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(BaseMonitor.java:227) at org.apache.derby.impl.services.monitor.FileMonitor.shutdown(FileMonitor.java:44) at org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(BaseMonitor.java:197) at org.apache.derby.impl.services.monitor.FileMonitor.shutdown(FileMonitor.java:44) at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:255) at org.apache.derby.jdbc.Driver20.connect(Driver20.java:246) at org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:145) at java.sql.DriverManager.getConnection(DriverManager.java:661) at java.sql.DriverManager.getConnection(DriverManager.java:208) at org.apache.derbyTesting.junit.DriverManagerConnector.getConnectionByAttributes(DriverManagerConnector.java:204) at org.apache.derbyTesting.junit.DriverManagerConnector.shutEngine(DriverManagerConnector.java:171) at org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1822) at org.apache.derbyTesting.functionTests.tests.derbynet.DerbyNetAutoStartTest.setUp(DerbyNetAutoStartTest.java:82) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) What's new in EA build 89 is that DriverManager.deregisterDriver() now requires an SQLPermission when running under a security manager. Most of suites.All runs under a security manager, and Derby's engine shutdown code calls deregisterDriver(), so this problem probably affects all tests that shut down the engine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6263) Make the Visitor support in CursorNodes support ORDER BY lists, FETCH, and OFFSET clauses
[ https://issues.apache.org/jira/browse/DERBY-6263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683453#comment-13683453 ] ASF subversion and git services commented on DERBY-6263: Commit 1493123 from [~rhillegas] [ https://svn.apache.org/r1493123 ] DERBY-6263: Make the Visitor logic inspect ORDER BY, FETCH, and OFFSET CLAUSES. Tests passed cleanly for me on derby-6263-01-aa-visit-ignored-clauses.diff. Make the Visitor support in CursorNodes support ORDER BY lists, FETCH, and OFFSET clauses - Key: DERBY-6263 URL: https://issues.apache.org/jira/browse/DERBY-6263 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.11.0.0 Reporter: Rick Hillegas Attachments: derby-6263-01-aa-visit-ignored-clauses.diff If you call treePrint() on a CursorNode, you will see information on ORDER BY, FETCH, and OFFSET clauses. However, these clauses are not visited by CursorNode.acceptChildren(). This looks like an omission. This defect was brought to our attention by this email thread: http://apache-database.10148.n7.nabble.com/Using-ASTParser-and-TreeWalker-for-parsing-SQL-query-td131219.html. You can see the difference in treePrint() and acceptChildren() behavior by running the following query through the ASTParser and TreePrinter tools attached to DERBY-3946: select tablename from sys.systables where 1=2 order by tablename; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6263) Make the Visitor support in CursorNodes support ORDER BY lists, FETCH, and OFFSET clauses
[ https://issues.apache.org/jira/browse/DERBY-6263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683458#comment-13683458 ] ASF subversion and git services commented on DERBY-6263: Commit 1493125 from [~rhillegas] [ https://svn.apache.org/r1493125 ] DERBY-6263: Port 1493123 from trunk to 10.10 branch. Make the Visitor support in CursorNodes support ORDER BY lists, FETCH, and OFFSET clauses - Key: DERBY-6263 URL: https://issues.apache.org/jira/browse/DERBY-6263 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.11.0.0 Reporter: Rick Hillegas Attachments: derby-6263-01-aa-visit-ignored-clauses.diff If you call treePrint() on a CursorNode, you will see information on ORDER BY, FETCH, and OFFSET clauses. However, these clauses are not visited by CursorNode.acceptChildren(). This looks like an omission. This defect was brought to our attention by this email thread: http://apache-database.10148.n7.nabble.com/Using-ASTParser-and-TreeWalker-for-parsing-SQL-query-td131219.html. You can see the difference in treePrint() and acceptChildren() behavior by running the following query through the ASTParser and TreePrinter tools attached to DERBY-3946: select tablename from sys.systables where 1=2 order by tablename; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6189) NPE involving temporary table and rollback
[ https://issues.apache.org/jira/browse/DERBY-6189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683494#comment-13683494 ] ASF subversion and git services commented on DERBY-6189: Commit 1493146 from [~rhillegas] [ https://svn.apache.org/r1493146 ] DERBY-6189: Merge 1469802 and 1469861 from trunk to 10.10 branch. NPE involving temporary table and rollback -- Key: DERBY-6189 URL: https://issues.apache.org/jira/browse/DERBY-6189 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.11.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: derby-6189-01-aa-invalidateTable.diff, derby-6189-02-aa-streamlineTest.diff, DERBY_6189.java I will attach a repro. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5172) testTimeAndDateWithCalendar (jdbcapi.CallableTest) fails intermittently with AssertionFailedError: hour expected: differs from actual.
[ https://issues.apache.org/jira/browse/DERBY-5172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683519#comment-13683519 ] ASF subversion and git services commented on DERBY-5172: Commit 1493154 from [~kmarsden] [ https://svn.apache.org/r1493154 ] DERBY-5172 testTimeAndDateWithCalendar (jdbcapi.CallableTest) fails intermittently with AssertionFailedError: hour expected: differs from actual. merge from trunk revision 1463874. Contributed by Knut Anders Hatlen testTimeAndDateWithCalendar (jdbcapi.CallableTest) fails intermittently with AssertionFailedError: hour expected: differs from actual. -- Key: DERBY-5172 URL: https://issues.apache.org/jira/browse/DERBY-5172 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.5.3.2, 10.7.1.4 Environment: IBM jvms 1.5 (SR12 FP3) and 1.6 (SR9 FP1), Suse Linux and Windows XP Reporter: Myrna van Lunteren Assignee: Knut Anders Hatlen Priority: Minor Labels: derby_triage10_10 Fix For: 10.11.0.0 Attachments: d5172-1a.diff, failing-timestamp.diff I've seen the following stack trace, for instance on 3/26/2011: http://people.apache.org/~myrnavl/derby_test_results/v10_7/windows/testlog/ibm16/1085854-suites.All_diff.txt 1) testTimeAndDateWithCalendar(org.apache.derbyTesting.functionTests.tests.jdbcapi.CallableTest)junit.framework.AssertionFailedError: hour expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.jdbcapi.CallableTest.assertSameTime(CallableTest.java:504) at org.apache.derbyTesting.functionTests.tests.jdbcapi.CallableTest.assertSameTimestamp(CallableTest.java:521) at org.apache.derbyTesting.functionTests.tests.jdbcapi.CallableTest.testTimeAndDateWithCalendar(CallableTest.java:456) at org.apache.derbyTesting.functionTests.tests.jdbcapi.CallableTest.testTimeAndDateWithCalendar(CallableTest.java:412) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:16) And another example, from http://people.apache.org/~myrnavl/derby_test_results/v10_5/windows/testlog/ibm16/1085628-suites.All_diff.txt: 1) testTimeAndDateWithCalendar(org.apache.derbyTesting.functionTests.tests.jdbcapi.CallableTest)junit.framework.AssertionFailedError: hour expected:18 but was:17 at org.apache.derbyTesting.functionTests.tests.jdbcapi.CallableTest.assertSameTime(CallableTest.java:512) at org.apache.derbyTesting.functionTests.tests.jdbcapi.CallableTest.assertSameTimestamp(CallableTest.java:529) at org.apache.derbyTesting.functionTests.tests.jdbcapi.CallableTest.testTimeAndDateWithCalendar(CallableTest.java:464) at org.apache.derbyTesting.functionTests.tests.jdbcapi.CallableTest.testTimeAndDateWithCalendar(CallableTest.java:412) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) As this is happening on two different code lines and on both linux and windows and I've recently updated the jvms, this could be a jvm issue, but that needs to be verified. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your
[jira] [Commented] (DERBY-3519) junit regression test failure in testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but
[ https://issues.apache.org/jira/browse/DERBY-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13683528#comment-13683528 ] ASF subversion and git services commented on DERBY-3519: Commit 1493156 from [~kmarsden] [ https://svn.apache.org/r1493156 ] DERBY-3519 junit regression test failure in testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 merge from trunk revision 1464386. Contributed by Knut Anders Hatlen junit regression test failure in testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 --- Key: DERBY-3519 URL: https://issues.apache.org/jira/browse/DERBY-3519 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.3.3.0, 10.4.1.3, 10.5.1.1, 10.8.3.0, 10.9.1.0 Reporter: Mike Matrigali Assignee: Knut Anders Hatlen Priority: Trivial Labels: derby_triage10_8 Fix For: 10.11.0.0 Attachments: d3519-1a.diff see ibm15 trunk testing: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/635136-suites.All_diff.txt There were 2 failures: 1) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testInertTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at unknown class.unknown method(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) 2) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.checkTimeValue(TimeHandlingTest.java:647) at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.testInertTime(TimeHandlingTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at unknown class.unknown method(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) FAILURES!!! Tests run: 8740, Failures: 2, Errors: 6 Also failed on j2me testing: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/weme6.1/635136-suites.All_diff.txt There were 2 failures: 1) testInertTime(org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest)junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.derbyTesting.functionTests.tests.lang.TimeHandlingTest.assertTimeEqual(TimeHandlingTest.java:927) at
[jira] [Commented] (DERBY-6257) Update link to Subversion home page on http://db.apache.org/derby/dev/derby_source.html
[ https://issues.apache.org/jira/browse/DERBY-6257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13684000#comment-13684000 ] ASF subversion and git services commented on DERBY-6257: Commit 1493293 from [~bryanpendleton] [ https://svn.apache.org/r1493293 ] DERBY-6257: Update link in website docs Changing the svn link in the website docs from tigris.org to apache.org. Update link to Subversion home page on http://db.apache.org/derby/dev/derby_source.html --- Key: DERBY-6257 URL: https://issues.apache.org/jira/browse/DERBY-6257 Project: Derby Issue Type: Bug Components: Web Site Reporter: Bryan Pendleton Assignee: Bryan Pendleton Priority: Trivial Attachments: docs.diff The Subversion home page has moved. The new home page is http://subversion.apache.org/ We should fix the link on http://db.apache.org/derby/dev/derby_source.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6253) Collapse SQLException factories
[ https://issues.apache.org/jira/browse/DERBY-6253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13685413#comment-13685413 ] ASF subversion and git services commented on DERBY-6253: Commit 1493701 from [~knutanders] [ https://svn.apache.org/r1493701 ] DERBY-6253: Collapse SQLException factories - Move functionality from SQLExceptionFactory40 to SQLExceptionFactory - Move logic for retrieving the exception factory from Util to ExceptionFactory in order to reduce compile-time dependencies on impl classes from iapi classes - Use varargs in Util's helper methods in order to reduce the number of methods Collapse SQLException factories --- Key: DERBY-6253 URL: https://issues.apache.org/jira/browse/DERBY-6253 Project: Derby Issue Type: Improvement Components: JDBC Affects Versions: 10.11.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: derby-6253-01-a.diff Both the client driver and the embedded driver have factories that produce SQLExceptions of the correct sub-type. We don't need the factories that produce JDBC 3.0 exceptions now that the base level is JDBC 4.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-1984) Re-factor JDBC classes to remove support for JDBC 2
[ https://issues.apache.org/jira/browse/DERBY-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13685418#comment-13685418 ] ASF subversion and git services commented on DERBY-1984: Commit 1493707 from [~knutanders] [ https://svn.apache.org/r1493707 ] DERBY-1984: Re-factor JDBC classes to remove support for JDBC 2 Move methods supporting JDBC versions up to 4.1 into the base class for the implementations of the following JDBC interfaces in the embedded driver: java.sql.ResultSet java.sql.DatabaseMetaData java.sql.ParameterMetaData java.sql.ResultSetMetaData Re-factor JDBC classes to remove support for JDBC 2 --- Key: DERBY-1984 URL: https://issues.apache.org/jira/browse/DERBY-1984 Project: Derby Issue Type: Sub-task Components: JDBC Reporter: Daniel John Debrunner Assignee: Knut Anders Hatlen Attachments: derby-1984-01-a.diff, derby-1984-01-b.diff, derby-1984-02-a.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6253) Collapse SQLException factories
[ https://issues.apache.org/jira/browse/DERBY-6253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13685420#comment-13685420 ] ASF subversion and git services commented on DERBY-6253: Commit 1493708 from [~knutanders] [ https://svn.apache.org/r1493708 ] DERBY-6253: Fix javadoc warning Collapse SQLException factories --- Key: DERBY-6253 URL: https://issues.apache.org/jira/browse/DERBY-6253 Project: Derby Issue Type: Improvement Components: JDBC Affects Versions: 10.11.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.11.0.0 Attachments: derby-6253-01-a.diff Both the client driver and the embedded driver have factories that produce SQLExceptions of the correct sub-type. We don't need the factories that produce JDBC 3.0 exceptions now that the base level is JDBC 4.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6262) Simplify message-generating methods using varargs
[ https://issues.apache.org/jira/browse/DERBY-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13685459#comment-13685459 ] ASF subversion and git services commented on DERBY-6262: Commit 1493714 from [~knutanders] [ https://svn.apache.org/r1493714 ] DERBY-6262: Simplify message-generating methods using varargs Simplify message-generating methods using varargs - Key: DERBY-6262 URL: https://issues.apache.org/jira/browse/DERBY-6262 Project: Derby Issue Type: Improvement Components: Miscellaneous Affects Versions: 10.11.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: derby-6262-01-a.diff I've found that many methods that generate messages could be collapsed into a single method using varargs. Right now, many of them exist in multiple variants, typically for zero up to three or four message arguments. Examples: Monitor.logTextMessage() MessageService.getTextMessage() Constructors in SqlException and SqlWarning -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6263) Make acceptChildren() overloads visit all clauses in QueryTreeNodes
[ https://issues.apache.org/jira/browse/DERBY-6263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13685626#comment-13685626 ] ASF subversion and git services commented on DERBY-6263: Commit 1493789 from [~rhillegas] [ https://svn.apache.org/r1493789 ] DERBY-6263: Add missing clauses to Visitor logic of SelectNode; tests passed cleanly on derby-6263-02-aa-ignored-clauses-in-SelectNode.diff. Make acceptChildren() overloads visit all clauses in QueryTreeNodes --- Key: DERBY-6263 URL: https://issues.apache.org/jira/browse/DERBY-6263 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.11.0.0 Reporter: Rick Hillegas Attachments: derby-6263-01-aa-visit-ignored-clauses.diff, derby-6263-02-aa-ignored-clauses-in-SelectNode.diff The acceptChildren() overloads don't visit all of the clauses in an AST node. This is probably a mistake. However, fixing it will require a systematic analysis of the AST nodes and probably some changes to the Visitors. Some queries rely on the fact that certain Visitors will not be called on some AST nodes even though the Visitors are called on sister nodes in the same parent AST node. An example of this defect is the CursorNode. If you call treePrint() on a CursorNode, you will see information on ORDER BY, FETCH, and OFFSET clauses. However, these clauses are not visited by CursorNode.acceptChildren(). This looks like an omission. This defect was brought to our attention by this email thread: http://apache-database.10148.n7.nabble.com/Using-ASTParser-and-TreeWalker-for-parsing-SQL-query-td131219.html. You can see the difference in treePrint() and acceptChildren() behavior by running the following query through the ASTParser and TreePrinter tools attached to DERBY-3946: select tablename from sys.systables where 1=2 order by tablename; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6263) Make acceptChildren() overloads visit all clauses in QueryTreeNodes
[ https://issues.apache.org/jira/browse/DERBY-6263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13685626#comment-13685626 ] ASF subversion and git services commented on DERBY-6263: Commit 1493789 from [~rhillegas] [ https://svn.apache.org/r1493789 ] DERBY-6263: Add missing clauses to Visitor logic of SelectNode; tests passed cleanly on derby-6263-02-aa-ignored-clauses-in-SelectNode.diff. Make acceptChildren() overloads visit all clauses in QueryTreeNodes --- Key: DERBY-6263 URL: https://issues.apache.org/jira/browse/DERBY-6263 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.11.0.0 Reporter: Rick Hillegas Attachments: derby-6263-01-aa-visit-ignored-clauses.diff, derby-6263-02-aa-ignored-clauses-in-SelectNode.diff The acceptChildren() overloads don't visit all of the clauses in an AST node. This is probably a mistake. However, fixing it will require a systematic analysis of the AST nodes and probably some changes to the Visitors. Some queries rely on the fact that certain Visitors will not be called on some AST nodes even though the Visitors are called on sister nodes in the same parent AST node. An example of this defect is the CursorNode. If you call treePrint() on a CursorNode, you will see information on ORDER BY, FETCH, and OFFSET clauses. However, these clauses are not visited by CursorNode.acceptChildren(). This looks like an omission. This defect was brought to our attention by this email thread: http://apache-database.10148.n7.nabble.com/Using-ASTParser-and-TreeWalker-for-parsing-SQL-query-td131219.html. You can see the difference in treePrint() and acceptChildren() behavior by running the following query through the ASTParser and TreePrinter tools attached to DERBY-3946: select tablename from sys.systables where 1=2 order by tablename; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6263) Make acceptChildren() overloads visit all clauses in QueryTreeNodes
[ https://issues.apache.org/jira/browse/DERBY-6263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13685631#comment-13685631 ] ASF subversion and git services commented on DERBY-6263: Commit 1493796 from [~rhillegas] [ https://svn.apache.org/r1493796 ] DERBY-6263: Port 1493789 from trunk to 10.10 branch. Make acceptChildren() overloads visit all clauses in QueryTreeNodes --- Key: DERBY-6263 URL: https://issues.apache.org/jira/browse/DERBY-6263 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.11.0.0 Reporter: Rick Hillegas Attachments: derby-6263-01-aa-visit-ignored-clauses.diff, derby-6263-02-aa-ignored-clauses-in-SelectNode.diff The acceptChildren() overloads don't visit all of the clauses in an AST node. This is probably a mistake. However, fixing it will require a systematic analysis of the AST nodes and probably some changes to the Visitors. Some queries rely on the fact that certain Visitors will not be called on some AST nodes even though the Visitors are called on sister nodes in the same parent AST node. An example of this defect is the CursorNode. If you call treePrint() on a CursorNode, you will see information on ORDER BY, FETCH, and OFFSET clauses. However, these clauses are not visited by CursorNode.acceptChildren(). This looks like an omission. This defect was brought to our attention by this email thread: http://apache-database.10148.n7.nabble.com/Using-ASTParser-and-TreeWalker-for-parsing-SQL-query-td131219.html. You can see the difference in treePrint() and acceptChildren() behavior by running the following query through the ASTParser and TreePrinter tools attached to DERBY-3946: select tablename from sys.systables where 1=2 order by tablename; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-1984) Re-factor JDBC classes to remove support for JDBC 2
[ https://issues.apache.org/jira/browse/DERBY-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13686509#comment-13686509 ] ASF subversion and git services commented on DERBY-1984: Commit 1494071 from [~knutanders] [ https://svn.apache.org/r1494071 ] DERBY-1984: Re-factor JDBC classes to remove support for JDBC 2 Collapse BrokeredStatement, BrokeredConnection, EngineConnection and EmbedConnection class hierarchies. Re-factor JDBC classes to remove support for JDBC 2 --- Key: DERBY-1984 URL: https://issues.apache.org/jira/browse/DERBY-1984 Project: Derby Issue Type: Sub-task Components: JDBC Reporter: Daniel John Debrunner Assignee: Knut Anders Hatlen Attachments: derby-1984-01-a.diff, derby-1984-01-b.diff, derby-1984-02-a.diff, derby-1984-03-a.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6266) Add ability to print a Derby execution ResultSet as xml.
[ https://issues.apache.org/jira/browse/DERBY-6266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13686647#comment-13686647 ] ASF subversion and git services commented on DERBY-6266: Commit 1494115 from [~rhillegas] [ https://svn.apache.org/r1494115 ] DERBY-6266: Add ability to print Derby execution ResultSet graph as xml. Add ability to print a Derby execution ResultSet as xml. Key: DERBY-6266 URL: https://issues.apache.org/jira/browse/DERBY-6266 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.11.0.0 Reporter: Rick Hillegas Attachments: derby-6266-01-aa-toXML.diff, z.sql Add a method for printing an org.apache.derby.iapi.sql.ResultSet as xml. The idea is to get a quick snapshot of a plan shape without all of the overhead of PlanExporter and runtimestatistics. This method could be used by our tests to verify plan shapes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6263) Make acceptChildren() overloads visit all clauses in QueryTreeNodes
[ https://issues.apache.org/jira/browse/DERBY-6263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13686990#comment-13686990 ] ASF subversion and git services commented on DERBY-6263: Commit 1494220 from [~rhillegas] [ https://svn.apache.org/r1494220 ] DERBY-6263: Add defensive code to Visitor support in SelectNode; tests passed cleanly on derby-6263-03-ab-defensiveNullChecking-in-SelectNode.diff. Make acceptChildren() overloads visit all clauses in QueryTreeNodes --- Key: DERBY-6263 URL: https://issues.apache.org/jira/browse/DERBY-6263 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.11.0.0 Reporter: Rick Hillegas Attachments: derby-6263-01-aa-visit-ignored-clauses.diff, derby-6263-02-aa-ignored-clauses-in-SelectNode.diff, derby-6263-03-aa-defensiveNullChecking-in-SelectNode.diff, derby-6263-03-ab-defensiveNullChecking-in-SelectNode.diff The acceptChildren() overloads don't visit all of the clauses in an AST node. This is probably a mistake. However, fixing it will require a systematic analysis of the AST nodes and probably some changes to the Visitors. Some queries rely on the fact that certain Visitors will not be called on some AST nodes even though the Visitors are called on sister nodes in the same parent AST node. An example of this defect is the CursorNode. If you call treePrint() on a CursorNode, you will see information on ORDER BY, FETCH, and OFFSET clauses. However, these clauses are not visited by CursorNode.acceptChildren(). This looks like an omission. This defect was brought to our attention by this email thread: http://apache-database.10148.n7.nabble.com/Using-ASTParser-and-TreeWalker-for-parsing-SQL-query-td131219.html. You can see the difference in treePrint() and acceptChildren() behavior by running the following query through the ASTParser and TreePrinter tools attached to DERBY-3946: select tablename from sys.systables where 1=2 order by tablename; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-1984) Re-factor JDBC classes to remove support for JDBC 2
[ https://issues.apache.org/jira/browse/DERBY-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13687723#comment-13687723 ] ASF subversion and git services commented on DERBY-1984: Commit 1494482 from [~knutanders] [ https://svn.apache.org/r1494482 ] DERBY-1984: Re-factor JDBC classes to remove support for JDBC 2 Move all functionality from Driver20, Driver30 and Driver40 to InternalDriver. Move all functionality from AutoloadedDriver40 to AutoloadedDriver. Re-factor JDBC classes to remove support for JDBC 2 --- Key: DERBY-1984 URL: https://issues.apache.org/jira/browse/DERBY-1984 Project: Derby Issue Type: Sub-task Components: JDBC Reporter: Daniel John Debrunner Assignee: Knut Anders Hatlen Attachments: derby-1984-01-a.diff, derby-1984-01-b.diff, derby-1984-02-a.diff, derby-1984-03-a.diff, derby-1984-04-a.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6262) Simplify message-generating methods using varargs
[ https://issues.apache.org/jira/browse/DERBY-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13687862#comment-13687862 ] ASF subversion and git services commented on DERBY-6262: Commit 1494541 from [~knutanders] [ https://svn.apache.org/r1494541 ] DERBY-6262: Simplify message-generating methods using varargs Use varargs in more constructors in SqlException and DisconnectException. Since the message arguments in some of those methods were not the last arguments, some reordering of arguments in the callers was needed. Simplify message-generating methods using varargs - Key: DERBY-6262 URL: https://issues.apache.org/jira/browse/DERBY-6262 Project: Derby Issue Type: Improvement Components: Miscellaneous Affects Versions: 10.11.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: derby-6262-01-a.diff, derby-6262-02-a.diff I've found that many methods that generate messages could be collapsed into a single method using varargs. Right now, many of them exist in multiple variants, typically for zero up to three or four message arguments. Examples: Monitor.logTextMessage() MessageService.getTextMessage() Constructors in SqlException and SqlWarning -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6224) Many test failures on latest JDK 8 EA build because of missing SQLPermission
[ https://issues.apache.org/jira/browse/DERBY-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13688372#comment-13688372 ] ASF subversion and git services commented on DERBY-6224: Commit 1494758 from [~knutanders] [ https://svn.apache.org/r1494758 ] DERBY-6224: Many test failures on latest JDK 8 EA build because of missing SQLPermission Merged revision 1493077 from trunk. Many test failures on latest JDK 8 EA build because of missing SQLPermission Key: DERBY-6224 URL: https://issues.apache.org/jira/browse/DERBY-6224 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.11.0.0 Environment: java version 1.8.0-ea Java(TM) SE Runtime Environment (build 1.8.0-ea-b89) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b31, mixed mode) Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.9.2.2, 10.10.1.2, 10.11.0.0 Attachments: derby-6224-01-a.diff, derby-6224-01-b.diff, derby-6224-02-a.diff, derby-6224-02-b-with-test.diff, releaseNote.html With the latest EA build of JDK 8 (build 1.8.0-ea-b89), I see many failures in suites.All. For example: 1) testStartNetworkServerFalse(org.apache.derbyTesting.functionTests.tests.derbynet.DerbyNetAutoStartTest)java.security.AccessControlException: access denied (java.sql.SQLPermission deregisterDriver) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:364) at java.security.AccessController.checkPermission(AccessController.java:562) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.sql.DriverManager.deregisterDriver(DriverManager.java:399) at org.apache.derby.jdbc.AutoloadedDriver.unregisterDriverModule(AutoloadedDriver.java:263) at org.apache.derby.jdbc.Driver20.stop(Driver20.java:105) at org.apache.derby.impl.services.monitor.TopService.stop(TopService.java:443) at org.apache.derby.impl.services.monitor.TopService.shutdown(TopService.java:394) at org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(BaseMonitor.java:227) at org.apache.derby.impl.services.monitor.FileMonitor.shutdown(FileMonitor.java:44) at org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(BaseMonitor.java:197) at org.apache.derby.impl.services.monitor.FileMonitor.shutdown(FileMonitor.java:44) at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:255) at org.apache.derby.jdbc.Driver20.connect(Driver20.java:246) at org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:145) at java.sql.DriverManager.getConnection(DriverManager.java:661) at java.sql.DriverManager.getConnection(DriverManager.java:208) at org.apache.derbyTesting.junit.DriverManagerConnector.getConnectionByAttributes(DriverManagerConnector.java:204) at org.apache.derbyTesting.junit.DriverManagerConnector.shutEngine(DriverManagerConnector.java:171) at org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1822) at org.apache.derbyTesting.functionTests.tests.derbynet.DerbyNetAutoStartTest.setUp(DerbyNetAutoStartTest.java:82) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) What's new in EA build 89 is that DriverManager.deregisterDriver() now requires an SQLPermission when running under a security manager. Most of suites.All runs under a security manager, and Derby's engine shutdown code calls deregisterDriver(), so this problem probably affects all tests that shut down the engine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6126) compatibility._Suite fails if derbyTesting.jar lives in different directory than product jars
[ https://issues.apache.org/jira/browse/DERBY-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13688990#comment-13688990 ] ASF subversion and git services commented on DERBY-6126: Commit 1494883 from [~knutanders] [ https://svn.apache.org/r1494883 ] DERBY-6126: compatibility._Suite fails if derbyTesting.jar lives in different directory than product jars Based on fix contributed by Kristian Waagan. compatibility._Suite fails if derbyTesting.jar lives in different directory than product jars - Key: DERBY-6126 URL: https://issues.apache.org/jira/browse/DERBY-6126 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.10.1.1 Reporter: Knut Anders Hatlen Attachments: derby-6126-1a-running_dist_jar_split_support.diff, derby-6126-1b.diff Seen when testing the 10.10.1.1 release candidate. In the releases, derbyTesting.jar lives in the test sub-directory and the product jars live in the lib directory. This breaks an assumption in the compatibility test framework, and suites.All won't even start. It works fine if you move derbyTesting.jar into the same directory as the product jars. FAILED to invoke org.apache.derbyTesting.functionTests.tests.compatibility._Suite java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.derbyTesting.functionTests.suites.AllPackages.invokeSuite(AllPackages.java:179) at org.apache.derbyTesting.functionTests.suites.AllPackages.addSuiteByReflection(AllPackages.java:149) at org.apache.derbyTesting.functionTests.suites.AllPackages.suite(AllPackages.java:61) at org.apache.derbyTesting.functionTests.suites.All.suite(All.java:51) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at junit.runner.BaseTestRunner.getTest(BaseTestRunner.java:126) at junit.textui.TestRunner.start(TestRunner.java:184) at junit.textui.TestRunner.main(TestRunner.java:143) Caused by: java.lang.IllegalStateException: failed to get running distribution (programming error?) at org.apache.derbyTesting.functionTests.tests.compatibility.VersionCombinationConfigurator.getRunningDistribution(VersionCombinationConfigurator.java:299) at org.apache.derbyTesting.functionTests.tests.compatibility.VersionCombinationConfigurator.filterVersions(VersionCombinationConfigurator.java:266) at org.apache.derbyTesting.functionTests.tests.compatibility.VersionCombinationConfigurator.addTests(VersionCombinationConfigurator.java:169) at org.apache.derbyTesting.functionTests.tests.compatibility._Suite.addVersionCombinations(_Suite.java:81) at org.apache.derbyTesting.functionTests.tests.compatibility._Suite.suite(_Suite.java:135) ... 15 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6126) compatibility._Suite fails if derbyTesting.jar lives in different directory than product jars
[ https://issues.apache.org/jira/browse/DERBY-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13688999#comment-13688999 ] ASF subversion and git services commented on DERBY-6126: Commit 1494884 from [~knutanders] [ https://svn.apache.org/r1494884 ] DERBY-6126: compatibility._Suite fails if derbyTesting.jar lives in different directory than product jars Merged revision 1494883 from trunk. compatibility._Suite fails if derbyTesting.jar lives in different directory than product jars - Key: DERBY-6126 URL: https://issues.apache.org/jira/browse/DERBY-6126 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.10.1.1 Reporter: Knut Anders Hatlen Attachments: derby-6126-1a-running_dist_jar_split_support.diff, derby-6126-1b.diff Seen when testing the 10.10.1.1 release candidate. In the releases, derbyTesting.jar lives in the test sub-directory and the product jars live in the lib directory. This breaks an assumption in the compatibility test framework, and suites.All won't even start. It works fine if you move derbyTesting.jar into the same directory as the product jars. FAILED to invoke org.apache.derbyTesting.functionTests.tests.compatibility._Suite java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.derbyTesting.functionTests.suites.AllPackages.invokeSuite(AllPackages.java:179) at org.apache.derbyTesting.functionTests.suites.AllPackages.addSuiteByReflection(AllPackages.java:149) at org.apache.derbyTesting.functionTests.suites.AllPackages.suite(AllPackages.java:61) at org.apache.derbyTesting.functionTests.suites.All.suite(All.java:51) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at junit.runner.BaseTestRunner.getTest(BaseTestRunner.java:126) at junit.textui.TestRunner.start(TestRunner.java:184) at junit.textui.TestRunner.main(TestRunner.java:143) Caused by: java.lang.IllegalStateException: failed to get running distribution (programming error?) at org.apache.derbyTesting.functionTests.tests.compatibility.VersionCombinationConfigurator.getRunningDistribution(VersionCombinationConfigurator.java:299) at org.apache.derbyTesting.functionTests.tests.compatibility.VersionCombinationConfigurator.filterVersions(VersionCombinationConfigurator.java:266) at org.apache.derbyTesting.functionTests.tests.compatibility.VersionCombinationConfigurator.addTests(VersionCombinationConfigurator.java:169) at org.apache.derbyTesting.functionTests.tests.compatibility._Suite.addVersionCombinations(_Suite.java:81) at org.apache.derbyTesting.functionTests.tests.compatibility._Suite.suite(_Suite.java:135) ... 15 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6224) Many test failures on latest JDK 8 EA build because of missing SQLPermission
[ https://issues.apache.org/jira/browse/DERBY-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13689020#comment-13689020 ] ASF subversion and git services commented on DERBY-6224: Commit 1494888 from [~knutanders] [ https://svn.apache.org/r1494888 ] DERBY-6224: Many test failures on latest JDK 8 EA build because of missing SQLPermission Compile the test against Java 5 libraries to prevent build issues when jsr169compile.classpath is set. Many test failures on latest JDK 8 EA build because of missing SQLPermission Key: DERBY-6224 URL: https://issues.apache.org/jira/browse/DERBY-6224 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.11.0.0 Environment: java version 1.8.0-ea Java(TM) SE Runtime Environment (build 1.8.0-ea-b89) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b31, mixed mode) Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.9.2.2, 10.10.1.2, 10.11.0.0 Attachments: buildbreak-10.10.diff, derby-6224-01-a.diff, derby-6224-01-b.diff, derby-6224-02-a.diff, derby-6224-02-b-with-test.diff, releaseNote.html With the latest EA build of JDK 8 (build 1.8.0-ea-b89), I see many failures in suites.All. For example: 1) testStartNetworkServerFalse(org.apache.derbyTesting.functionTests.tests.derbynet.DerbyNetAutoStartTest)java.security.AccessControlException: access denied (java.sql.SQLPermission deregisterDriver) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:364) at java.security.AccessController.checkPermission(AccessController.java:562) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.sql.DriverManager.deregisterDriver(DriverManager.java:399) at org.apache.derby.jdbc.AutoloadedDriver.unregisterDriverModule(AutoloadedDriver.java:263) at org.apache.derby.jdbc.Driver20.stop(Driver20.java:105) at org.apache.derby.impl.services.monitor.TopService.stop(TopService.java:443) at org.apache.derby.impl.services.monitor.TopService.shutdown(TopService.java:394) at org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(BaseMonitor.java:227) at org.apache.derby.impl.services.monitor.FileMonitor.shutdown(FileMonitor.java:44) at org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(BaseMonitor.java:197) at org.apache.derby.impl.services.monitor.FileMonitor.shutdown(FileMonitor.java:44) at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:255) at org.apache.derby.jdbc.Driver20.connect(Driver20.java:246) at org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:145) at java.sql.DriverManager.getConnection(DriverManager.java:661) at java.sql.DriverManager.getConnection(DriverManager.java:208) at org.apache.derbyTesting.junit.DriverManagerConnector.getConnectionByAttributes(DriverManagerConnector.java:204) at org.apache.derbyTesting.junit.DriverManagerConnector.shutEngine(DriverManagerConnector.java:171) at org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1822) at org.apache.derbyTesting.functionTests.tests.derbynet.DerbyNetAutoStartTest.setUp(DerbyNetAutoStartTest.java:82) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) What's new in EA build 89 is that DriverManager.deregisterDriver() now requires an SQLPermission when running under a security manager. Most of suites.All runs under a security manager, and Derby's engine shutdown code calls deregisterDriver(), so this problem probably affects all tests that shut down the engine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6126) compatibility._Suite fails if derbyTesting.jar lives in different directory than product jars
[ https://issues.apache.org/jira/browse/DERBY-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13689077#comment-13689077 ] ASF subversion and git services commented on DERBY-6126: Commit 1494901 from [~knutanders] [ https://svn.apache.org/r1494901 ] DERBY-6126: Fix javadoc warning compatibility._Suite fails if derbyTesting.jar lives in different directory than product jars - Key: DERBY-6126 URL: https://issues.apache.org/jira/browse/DERBY-6126 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.10.1.1 Reporter: Knut Anders Hatlen Assignee: Kristian Waagan Fix For: 10.10.1.2, 10.11.0.0 Attachments: derby-6126-1a-running_dist_jar_split_support.diff, derby-6126-1b.diff Seen when testing the 10.10.1.1 release candidate. In the releases, derbyTesting.jar lives in the test sub-directory and the product jars live in the lib directory. This breaks an assumption in the compatibility test framework, and suites.All won't even start. It works fine if you move derbyTesting.jar into the same directory as the product jars. FAILED to invoke org.apache.derbyTesting.functionTests.tests.compatibility._Suite java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.derbyTesting.functionTests.suites.AllPackages.invokeSuite(AllPackages.java:179) at org.apache.derbyTesting.functionTests.suites.AllPackages.addSuiteByReflection(AllPackages.java:149) at org.apache.derbyTesting.functionTests.suites.AllPackages.suite(AllPackages.java:61) at org.apache.derbyTesting.functionTests.suites.All.suite(All.java:51) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at junit.runner.BaseTestRunner.getTest(BaseTestRunner.java:126) at junit.textui.TestRunner.start(TestRunner.java:184) at junit.textui.TestRunner.main(TestRunner.java:143) Caused by: java.lang.IllegalStateException: failed to get running distribution (programming error?) at org.apache.derbyTesting.functionTests.tests.compatibility.VersionCombinationConfigurator.getRunningDistribution(VersionCombinationConfigurator.java:299) at org.apache.derbyTesting.functionTests.tests.compatibility.VersionCombinationConfigurator.filterVersions(VersionCombinationConfigurator.java:266) at org.apache.derbyTesting.functionTests.tests.compatibility.VersionCombinationConfigurator.addTests(VersionCombinationConfigurator.java:169) at org.apache.derbyTesting.functionTests.tests.compatibility._Suite.addVersionCombinations(_Suite.java:81) at org.apache.derbyTesting.functionTests.tests.compatibility._Suite.suite(_Suite.java:135) ... 15 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6126) compatibility._Suite fails if derbyTesting.jar lives in different directory than product jars
[ https://issues.apache.org/jira/browse/DERBY-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13689082#comment-13689082 ] ASF subversion and git services commented on DERBY-6126: Commit 1494903 from [~knutanders] [ https://svn.apache.org/r1494903 ] DERBY-6126: Fix javadoc warning compatibility._Suite fails if derbyTesting.jar lives in different directory than product jars - Key: DERBY-6126 URL: https://issues.apache.org/jira/browse/DERBY-6126 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.10.1.1 Reporter: Knut Anders Hatlen Assignee: Kristian Waagan Fix For: 10.10.1.2, 10.11.0.0 Attachments: derby-6126-1a-running_dist_jar_split_support.diff, derby-6126-1b.diff Seen when testing the 10.10.1.1 release candidate. In the releases, derbyTesting.jar lives in the test sub-directory and the product jars live in the lib directory. This breaks an assumption in the compatibility test framework, and suites.All won't even start. It works fine if you move derbyTesting.jar into the same directory as the product jars. FAILED to invoke org.apache.derbyTesting.functionTests.tests.compatibility._Suite java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.derbyTesting.functionTests.suites.AllPackages.invokeSuite(AllPackages.java:179) at org.apache.derbyTesting.functionTests.suites.AllPackages.addSuiteByReflection(AllPackages.java:149) at org.apache.derbyTesting.functionTests.suites.AllPackages.suite(AllPackages.java:61) at org.apache.derbyTesting.functionTests.suites.All.suite(All.java:51) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at junit.runner.BaseTestRunner.getTest(BaseTestRunner.java:126) at junit.textui.TestRunner.start(TestRunner.java:184) at junit.textui.TestRunner.main(TestRunner.java:143) Caused by: java.lang.IllegalStateException: failed to get running distribution (programming error?) at org.apache.derbyTesting.functionTests.tests.compatibility.VersionCombinationConfigurator.getRunningDistribution(VersionCombinationConfigurator.java:299) at org.apache.derbyTesting.functionTests.tests.compatibility.VersionCombinationConfigurator.filterVersions(VersionCombinationConfigurator.java:266) at org.apache.derbyTesting.functionTests.tests.compatibility.VersionCombinationConfigurator.addTests(VersionCombinationConfigurator.java:169) at org.apache.derbyTesting.functionTests.tests.compatibility._Suite.addVersionCombinations(_Suite.java:81) at org.apache.derbyTesting.functionTests.tests.compatibility._Suite.suite(_Suite.java:135) ... 15 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6224) Many test failures on latest JDK 8 EA build because of missing SQLPermission
[ https://issues.apache.org/jira/browse/DERBY-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13689175#comment-13689175 ] ASF subversion and git services commented on DERBY-6224: Commit 1494947 from [~knutanders] [ https://svn.apache.org/r1494947 ] DERBY-6224: Many test failures on latest JDK 8 EA build because of missing SQLPermission Merged revisions 1494758 and 1494888 from 10.10. Many test failures on latest JDK 8 EA build because of missing SQLPermission Key: DERBY-6224 URL: https://issues.apache.org/jira/browse/DERBY-6224 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.11.0.0 Environment: java version 1.8.0-ea Java(TM) SE Runtime Environment (build 1.8.0-ea-b89) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b31, mixed mode) Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.9.2.2, 10.10.1.2, 10.11.0.0 Attachments: buildbreak-10.10.diff, derby-6224-01-a.diff, derby-6224-01-b.diff, derby-6224-02-a.diff, derby-6224-02-b-with-test.diff, releaseNote.html With the latest EA build of JDK 8 (build 1.8.0-ea-b89), I see many failures in suites.All. For example: 1) testStartNetworkServerFalse(org.apache.derbyTesting.functionTests.tests.derbynet.DerbyNetAutoStartTest)java.security.AccessControlException: access denied (java.sql.SQLPermission deregisterDriver) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:364) at java.security.AccessController.checkPermission(AccessController.java:562) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.sql.DriverManager.deregisterDriver(DriverManager.java:399) at org.apache.derby.jdbc.AutoloadedDriver.unregisterDriverModule(AutoloadedDriver.java:263) at org.apache.derby.jdbc.Driver20.stop(Driver20.java:105) at org.apache.derby.impl.services.monitor.TopService.stop(TopService.java:443) at org.apache.derby.impl.services.monitor.TopService.shutdown(TopService.java:394) at org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(BaseMonitor.java:227) at org.apache.derby.impl.services.monitor.FileMonitor.shutdown(FileMonitor.java:44) at org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(BaseMonitor.java:197) at org.apache.derby.impl.services.monitor.FileMonitor.shutdown(FileMonitor.java:44) at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:255) at org.apache.derby.jdbc.Driver20.connect(Driver20.java:246) at org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:145) at java.sql.DriverManager.getConnection(DriverManager.java:661) at java.sql.DriverManager.getConnection(DriverManager.java:208) at org.apache.derbyTesting.junit.DriverManagerConnector.getConnectionByAttributes(DriverManagerConnector.java:204) at org.apache.derbyTesting.junit.DriverManagerConnector.shutEngine(DriverManagerConnector.java:171) at org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1822) at org.apache.derbyTesting.functionTests.tests.derbynet.DerbyNetAutoStartTest.setUp(DerbyNetAutoStartTest.java:82) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) What's new in EA build 89 is that DriverManager.deregisterDriver() now requires an SQLPermission when running under a security manager. Most of suites.All runs under a security manager, and Derby's engine shutdown code calls deregisterDriver(), so this problem probably affects all tests that shut down the engine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6211) Make Optimizer trace logic pluggable.
[ https://issues.apache.org/jira/browse/DERBY-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13689189#comment-13689189 ] ASF subversion and git services commented on DERBY-6211: Commit 1494954 from [~rhillegas] [ https://svn.apache.org/r1494954 ] DERBY-6211: Use schema-qualified names in plan summaries printed by the xml-based optimizer tracer; commit derby-6211-07-ab-useSchemaQualifiedNamesInSummaries.diff. Make Optimizer trace logic pluggable. - Key: DERBY-6211 URL: https://issues.apache.org/jira/browse/DERBY-6211 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.11.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: derby-6211-01-aa-createPlugin.diff, derby-6211-02-aa-cleanup.diff, derby-6211-02-ab-cleanup.diff, derby-6211-03-aa-customTracer.diff, derby-6211-04-aa-moveOptimizerTracerToEngineJar.diff, derby-6211-05-aa-xmlOptimizerTracer.diff, derby-6211-06-ab-packageProtect-XMLOptTrace.diff, derby-6211-07-aa-useSchemaQualifiedNamesInSummaries.diff, derby-6211-07-ab-useSchemaQualifiedNamesInSummaries.diff Right now the trace logic in the optimizer is hard-coded to produce a stream of diagnostics. It would be good to be able to plug alternative trace logic into the optimizer. This would make the following possible: 1) Plug in trace logic which produces formats which are easier to study and which can be analyzed mechanically. E.g., xml formatted output. 2) Plug in trace logic which can be used during unit testing to verify that the optimizer has picked the right plan. Over time this might make it easier to migrate canon-based tests to assertion-based tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6262) Simplify message-generating methods using varargs
[ https://issues.apache.org/jira/browse/DERBY-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13689285#comment-13689285 ] ASF subversion and git services commented on DERBY-6262: Commit 1495023 from [~knutanders] [ https://svn.apache.org/r1495023 ] DERBY-6262: Simplify message-generating methods using varargs Reduce number of methods that format messages in tools classes. Simplify message-generating methods using varargs - Key: DERBY-6262 URL: https://issues.apache.org/jira/browse/DERBY-6262 Project: Derby Issue Type: Improvement Components: Miscellaneous Affects Versions: 10.11.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: derby-6262-01-a.diff, derby-6262-02-a.diff, derby-6262-03-a.diff I've found that many methods that generate messages could be collapsed into a single method using varargs. Right now, many of them exist in multiple variants, typically for zero up to three or four message arguments. Examples: Monitor.logTextMessage() MessageService.getTextMessage() Constructors in SqlException and SqlWarning -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-1984) Re-factor JDBC classes to remove support for JDBC 2
[ https://issues.apache.org/jira/browse/DERBY-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13689287#comment-13689287 ] ASF subversion and git services commented on DERBY-1984: Commit 1495024 from [~knutanders] [ https://svn.apache.org/r1495024 ] DERBY-1984: Re-factor JDBC classes to remove support for JDBC 2 Remove version-specific sub-classes of EmbedPooledConnection and EmbedXAConnection. Re-factor JDBC classes to remove support for JDBC 2 --- Key: DERBY-1984 URL: https://issues.apache.org/jira/browse/DERBY-1984 Project: Derby Issue Type: Sub-task Components: JDBC Reporter: Daniel John Debrunner Assignee: Knut Anders Hatlen Attachments: derby-1984-01-a.diff, derby-1984-01-b.diff, derby-1984-02-a.diff, derby-1984-03-a.diff, derby-1984-04-a.diff, derby-1984-05-a.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6224) Many test failures on latest JDK 8 EA build because of missing SQLPermission
[ https://issues.apache.org/jira/browse/DERBY-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13689301#comment-13689301 ] ASF subversion and git services commented on DERBY-6224: Commit 1495035 from [~knutanders] [ https://svn.apache.org/r1495035 ] DERBY-6224: Many test failures on latest JDK 8 EA build because of missing SQLPermission Merged revisions 1490291 and 1494947 from 10.9. Many test failures on latest JDK 8 EA build because of missing SQLPermission Key: DERBY-6224 URL: https://issues.apache.org/jira/browse/DERBY-6224 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.11.0.0 Environment: java version 1.8.0-ea Java(TM) SE Runtime Environment (build 1.8.0-ea-b89) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b31, mixed mode) Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.9.2.2, 10.10.1.2, 10.11.0.0 Attachments: buildbreak-10.10.diff, derby-6224-01-a.diff, derby-6224-01-b.diff, derby-6224-02-a.diff, derby-6224-02-b-with-test.diff, releaseNote.html With the latest EA build of JDK 8 (build 1.8.0-ea-b89), I see many failures in suites.All. For example: 1) testStartNetworkServerFalse(org.apache.derbyTesting.functionTests.tests.derbynet.DerbyNetAutoStartTest)java.security.AccessControlException: access denied (java.sql.SQLPermission deregisterDriver) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:364) at java.security.AccessController.checkPermission(AccessController.java:562) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.sql.DriverManager.deregisterDriver(DriverManager.java:399) at org.apache.derby.jdbc.AutoloadedDriver.unregisterDriverModule(AutoloadedDriver.java:263) at org.apache.derby.jdbc.Driver20.stop(Driver20.java:105) at org.apache.derby.impl.services.monitor.TopService.stop(TopService.java:443) at org.apache.derby.impl.services.monitor.TopService.shutdown(TopService.java:394) at org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(BaseMonitor.java:227) at org.apache.derby.impl.services.monitor.FileMonitor.shutdown(FileMonitor.java:44) at org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(BaseMonitor.java:197) at org.apache.derby.impl.services.monitor.FileMonitor.shutdown(FileMonitor.java:44) at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:255) at org.apache.derby.jdbc.Driver20.connect(Driver20.java:246) at org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:145) at java.sql.DriverManager.getConnection(DriverManager.java:661) at java.sql.DriverManager.getConnection(DriverManager.java:208) at org.apache.derbyTesting.junit.DriverManagerConnector.getConnectionByAttributes(DriverManagerConnector.java:204) at org.apache.derbyTesting.junit.DriverManagerConnector.shutEngine(DriverManagerConnector.java:171) at org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1822) at org.apache.derbyTesting.functionTests.tests.derbynet.DerbyNetAutoStartTest.setUp(DerbyNetAutoStartTest.java:82) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) What's new in EA build 89 is that DriverManager.deregisterDriver() now requires an SQLPermission when running under a security manager. Most of suites.All runs under a security manager, and Derby's engine shutdown code calls deregisterDriver(), so this problem probably affects all tests that shut down the engine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-673) Get rid of the NodeFactory
[ https://issues.apache.org/jira/browse/DERBY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13690166#comment-13690166 ] ASF subversion and git services commented on DERBY-673: --- Commit 1495361 from [~knutanders] [ https://svn.apache.org/r1495361 ] DERBY-673: Fixed javadoc warnings. Get rid of the NodeFactory -- Key: DERBY-673 URL: https://issues.apache.org/jira/browse/DERBY-673 Project: Derby Issue Type: Improvement Components: SQL Reporter: Rick Hillegas Assignee: Dag H. Wanvik Attachments: derby-673-1.diff.gz, derby-673-1.status, derby-673-2.diff.gz, derby-673-2.status, derby-673-3.diff.gz, derby-673-3.status, derby-673-fixcomments.diff, nodefactory-31.status, nodefactory-31.zip This piece of code once had a purpose in life. It was one of the double-joints which allowed cloudscape to ship with and without compiler support for the synchronization language. Synchronization has been removed. If we want to plug in optional language components, I think there are better ways to do this. The NodeFactory turned into a big, sprawling piece of code. At some point this code was slimmed down by telescoping all of its factory methods into a couple unwieldly, weakly-typed overloads backed by cumbersome logic in the actual node constructors. I would like to reintroduce strongly typed node constructors which the parser can call directly. This will make node generation easier to read and less brittle and it will get rid of the now useless NodeFactory class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6213) Deprecate support for Java 5 and CDC
[ https://issues.apache.org/jira/browse/DERBY-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13690367#comment-13690367 ] ASF subversion and git services commented on DERBY-6213: Commit 1495471 from [~rhillegas] [ https://svn.apache.org/r1495471 ] DERBY-6213: Remove more references to EmbeddedSimpleDataSource; tests passed cleanly on derby-6213-25-aa-remove-reflective-references-to-EmbeddedSimpleDataSource.diff. Deprecate support for Java 5 and CDC Key: DERBY-6213 URL: https://issues.apache.org/jira/browse/DERBY-6213 Project: Derby Issue Type: Improvement Components: Build tools, Documentation, Javadoc Affects Versions: 10.11.0.0 Reporter: Rick Hillegas Attachments: buildbreak2-datasource.diff, buildbreak.diff, client.diff, deprecate-datasources.diff, derby-6213-01-aa-collapsePublishedAPI.diff, derby-6213-02-aa-org.apache.derby.vti.diff, derby-6213-03-aa-misc.diff, derby-6213-03-ab-misc.diff, derby-6213-04-aa-vtiPackageOnJava7.diff, derby-6213-05-ab-misc2.diff, derby-6213-06-aa-convertProductToJava6.diff, derby-6213-06-ab-removeCDC.diff, derby-6213-07-aa-restOfProductExceptJDBC.diff, derby-6213-08-ab-jdbc.diff, derby-6213-09-ab-lint1.diff, derby-6213-10-aa-lint2-implServices.diff, derby-6213-11-aa-lint3-implStore.diff, derby-6213-12-aa-lint4-implSqlCatalog-implSqlDepend.diff, derby-6213-13-aa-lint4-implSqlConn.diff, derby-6213-14-aa-lint6-implSqlCompile-implSqlExecute.diff, derby-6213-15-aa-lint7.diff, derby-6213-16-aa-lint8.diff, derby-6213-17-aa-lint9.diff, derby-6213-17-ab-lint9.diff, derby-6213-18-aa-collapseEmbeddedDataSources.diff, derby-6213-20-aa-remove.java15.compile.classpath.diff, derby-6213-21-aa-felixLint.diff, derby-6213-22-aa-remove1.4and1.5sourceAndTargetLevels.diff, derby-6213-23-aa-removeSimpleMobileApp.diff, derby-6213-24-aa-makeBasicConnectionPoolDataSource40public.diff, derby-6213-25-aa-remove-reflective-references-to-EmbeddedSimpleDataSource.diff, descriptor-lists.diff, jvminfo-j2me.diff, jvminfo-oldconstants.diff, releaseNote.html, releaseNote.html, revive-sqlxmlutil-target.diff, simplify-with-java5.diff, simplify-with-java5-v2.diff, testcode.diff The developer community has approved the proposal to sunset support for Java 5 and CDC: http://apache-database.10148.n7.nabble.com/VOTE-Sunsetting-support-for-Java-5-and-CDC-td129832.html#a129925 This issue tracks a number of tasks needed to implement this proposal: I) Remove build support for Java 5 and CDC. II) Purge user doc references to Java 5, CDC, and the JDBC 4 DataSources. III) Remove the JDBC 4 version of the public api from the published javadoc. The recently introduced CP2 DataSources would need to migrate to the JDBC 3 version of the published javadoc. The JDBC 4 versions of the DataSources would still exist, but they would be vacuous extensions of their JDBC 3 counterparts. IV) On the wiki, document our expectation that maintenance releases will support the same platforms as the original feature release cut from their branch. V) Decide what to do with the SimpleMobileApp. Probably we want to just remove this demo since its purpose is to show how to run Derby on the deprecated CDC platform. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6268) Run-time statistics not collected if query contains always false predicate
[ https://issues.apache.org/jira/browse/DERBY-6268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13691766#comment-13691766 ] ASF subversion and git services commented on DERBY-6268: Commit 1495943 from [~knutanders] [ https://svn.apache.org/r1495943 ] DERBY-6268: Run-time statistics not collected if query contains always false predicate Make ProjectRestrictResultSet.close() call super.close() so that the logic for dumping run-time statistics gets executed. Run-time statistics not collected if query contains always false predicate -- Key: DERBY-6268 URL: https://issues.apache.org/jira/browse/DERBY-6268 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.6.2.1, 10.7.1.1, 10.8.3.0, 10.9.1.0, 10.10.1.1 Reporter: Knut Anders Hatlen Labels: derby_triage10_11 Attachments: derby-6268-01-a.diff Run-time statistics don't seem to be collected if the query contains a predicate that is known to always evaluate to false. See this thread on derby-dev: http://mail-archives.apache.org/mod_mbox/db-derby-dev/201306.mbox/%3C51BF194D.5040207%40oracle.com%3E -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6268) Run-time statistics not collected if query contains always false predicate
[ https://issues.apache.org/jira/browse/DERBY-6268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13691890#comment-13691890 ] ASF subversion and git services commented on DERBY-6268: Commit 1495991 from [~knutanders] [ https://svn.apache.org/r1495991 ] DERBY-6268: Run-time statistics not collected if query contains always false predicate Merged revision 1495943 from trunk. Run-time statistics not collected if query contains always false predicate -- Key: DERBY-6268 URL: https://issues.apache.org/jira/browse/DERBY-6268 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.6.2.1, 10.7.1.1, 10.8.3.0, 10.9.1.0, 10.10.1.1 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Labels: derby_triage10_11 Fix For: 10.11.0.0 Attachments: derby-6268-01-a.diff Run-time statistics don't seem to be collected if the query contains a predicate that is known to always evaluate to false. See this thread on derby-dev: http://mail-archives.apache.org/mod_mbox/db-derby-dev/201306.mbox/%3C51BF194D.5040207%40oracle.com%3E -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6272) LoginTimeoutTest fails if server is missing
[ https://issues.apache.org/jira/browse/DERBY-6272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13692929#comment-13692929 ] ASF subversion and git services commented on DERBY-6272: Commit 1496406 from [~knutanders] [ https://svn.apache.org/r1496406 ] DERBY-6272: LoginTimeoutTest fails if server is missing LoginTimeoutTest fails if server is missing --- Key: DERBY-6272 URL: https://issues.apache.org/jira/browse/DERBY-6272 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.10.1.1 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: derby-6272-01-a.diff When I run LoginTimeoutTest without derbynet.jar on the classpath, I see this failure: There was 1 error: 1) client/server LoginTimeoutTestjava.lang.NoClassDefFoundError: org/apache/derby/drda/NetworkServerControl at org.apache.derbyTesting.junit.NetworkServerTestSetup.getNetworkServerControl(NetworkServerTestSetup.java:506) at org.apache.derbyTesting.junit.NetworkServerTestSetup.setUp(NetworkServerTestSetup.java:195) at junit.extensions.TestSetup$1.protect(TestSetup.java:20) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) Caused by: java.lang.ClassNotFoundException: org.apache.derby.drda.NetworkServerControl at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 11 more Other tests skip client/server testing if the client or the server is missing. LoginTimeoutTest should do the same. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6262) Simplify message-generating methods using varargs
[ https://issues.apache.org/jira/browse/DERBY-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13692931#comment-13692931 ] ASF subversion and git services commented on DERBY-6262: Commit 1496410 from [~knutanders] [ https://svn.apache.org/r1496410 ] DERBY-6262: Simplify message-generating methods using varargs Reduce number of trace methods in LogWriter using varargs and auto-boxing. Simplify message-generating methods using varargs - Key: DERBY-6262 URL: https://issues.apache.org/jira/browse/DERBY-6262 Project: Derby Issue Type: Improvement Components: Miscellaneous Affects Versions: 10.11.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: derby-6262-01-a.diff, derby-6262-02-a.diff, derby-6262-03-a.diff, derby-6262-04-a.diff I've found that many methods that generate messages could be collapsed into a single method using varargs. Right now, many of them exist in multiple variants, typically for zero up to three or four message arguments. Examples: Monitor.logTextMessage() MessageService.getTextMessage() Constructors in SqlException and SqlWarning -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6258) Restrict permissions on BACKUP.HISTORY
[ https://issues.apache.org/jira/browse/DERBY-6258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13692942#comment-13692942 ] ASF subversion and git services commented on DERBY-6258: Commit 1496425 from [~knutanders] [ https://svn.apache.org/r1496425 ] DERBY-6258: Restrict permissions on BACKUP.HISTORY Merged revision 1492110 from trunk. Restrict permissions on BACKUP.HISTORY -- Key: DERBY-6258 URL: https://issues.apache.org/jira/browse/DERBY-6258 Project: Derby Issue Type: Improvement Components: Store Affects Versions: 10.9.1.0, 10.10.1.1 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.11.0.0 Attachments: derby-6258-01-a.diff DirFile4.getOutputStream(boolean) does not restrict the file permissions on the file if it ends up creating a new file. This method is only used for writing to BACKUP.HISTORY during backup. The BACKUP.HISTORY file in the backup does have restricted file permissions, it is only the file in the original database that is created with less restrictive permissions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6262) Simplify message-generating methods using varargs
[ https://issues.apache.org/jira/browse/DERBY-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13692978#comment-13692978 ] ASF subversion and git services commented on DERBY-6262: Commit 1496449 from [~knutanders] [ https://svn.apache.org/r1496449 ] DERBY-6262: Simplify message-generating methods using varargs Use varargs in EmbedConnection.newSQLException() and ConnectionChild.newSQLException(). Simplify message-generating methods using varargs - Key: DERBY-6262 URL: https://issues.apache.org/jira/browse/DERBY-6262 Project: Derby Issue Type: Improvement Components: Miscellaneous Affects Versions: 10.11.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: derby-6262-01-a.diff, derby-6262-02-a.diff, derby-6262-03-a.diff, derby-6262-04-a.diff, derby-6262-05-a.diff I've found that many methods that generate messages could be collapsed into a single method using varargs. Right now, many of them exist in multiple variants, typically for zero up to three or four message arguments. Examples: Monitor.logTextMessage() MessageService.getTextMessage() Constructors in SqlException and SqlWarning -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6272) LoginTimeoutTest fails if server is missing
[ https://issues.apache.org/jira/browse/DERBY-6272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13692996#comment-13692996 ] ASF subversion and git services commented on DERBY-6272: Commit 1496455 from [~knutanders] [ https://svn.apache.org/r1496455 ] DERBY-6272: LoginTimeoutTest fails if server is missing Merged revision 1496406 from trunk. LoginTimeoutTest fails if server is missing --- Key: DERBY-6272 URL: https://issues.apache.org/jira/browse/DERBY-6272 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.10.1.1 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: derby-6272-01-a.diff When I run LoginTimeoutTest without derbynet.jar on the classpath, I see this failure: There was 1 error: 1) client/server LoginTimeoutTestjava.lang.NoClassDefFoundError: org/apache/derby/drda/NetworkServerControl at org.apache.derbyTesting.junit.NetworkServerTestSetup.getNetworkServerControl(NetworkServerTestSetup.java:506) at org.apache.derbyTesting.junit.NetworkServerTestSetup.setUp(NetworkServerTestSetup.java:195) at junit.extensions.TestSetup$1.protect(TestSetup.java:20) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) Caused by: java.lang.ClassNotFoundException: org.apache.derby.drda.NetworkServerControl at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 11 more Other tests skip client/server testing if the client or the server is missing. LoginTimeoutTest should do the same. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6273) NullPointerException when using more than one parameter in COALESCE
[ https://issues.apache.org/jira/browse/DERBY-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13693843#comment-13693843 ] ASF subversion and git services commented on DERBY-6273: Commit 1496837 from [~knutanders] [ https://svn.apache.org/r1496837 ] DERBY-6273: NullPointerException when using more than one parameter in COALESCE NullPointerException when using more than one parameter in COALESCE --- Key: DERBY-6273 URL: https://issues.apache.org/jira/browse/DERBY-6273 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.10.1.1 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Attachments: derby-6273-01-a.diff Calls to COALESCE fail with NullPointerExceptions if there are multiple ? parameters: ij version 10.10 ij connect 'jdbc:derby:memory:db;create=true'; ij prepare ps as 'values coalesce(?,?,1)'; ERROR XJ001: Java exception: ': java.lang.NullPointerException'. (errorCode = 0) java.lang.NullPointerException at org.apache.derby.impl.sql.compile.ParameterNode.generateExpression(Unknown Source) at org.apache.derby.impl.sql.compile.CoalesceFunctionNode.generateExpression(Unknown Source) at org.apache.derby.impl.sql.compile.ResultColumn.generateExpression(Unknown Source) at org.apache.derby.impl.sql.compile.ResultColumnList.generateCore(Unknown Source) at org.apache.derby.impl.sql.compile.ResultColumnList.generate(Unknown Source) at org.apache.derby.impl.sql.compile.RowResultSetNode.generate(Unknown Source) at org.apache.derby.impl.sql.compile.ScrollInsensitiveResultSetNode.generate(Unknown Source) at org.apache.derby.impl.sql.compile.CursorNode.generate(Unknown Source) at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown Source) at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.apache.derby.impl.tools.ij.ij.PrepareStatement(Unknown Source) at org.apache.derby.impl.tools.ij.ij.ijStatement(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source) at org.apache.derby.impl.tools.ij.Main.go(Unknown Source) at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source) at org.apache.derby.impl.tools.ij.Main.main(Unknown Source) at org.apache.derby.tools.ij.main(Unknown Source) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6114) OOME in XAMemTest.testDerby4137_TransactionTimeoutSpecifiedNotExceeded
[ https://issues.apache.org/jira/browse/DERBY-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13693872#comment-13693872 ] ASF subversion and git services commented on DERBY-6114: Commit 1496859 from [~knutanders] [ https://svn.apache.org/r1496859 ] DERBY-6114: OOME in XAMemTest.testDerby4137_TransactionTimeoutSpecifiedNotExceeded Merged revision 1492127 from 10.10. OOME in XAMemTest.testDerby4137_TransactionTimeoutSpecifiedNotExceeded -- Key: DERBY-6114 URL: https://issues.apache.org/jira/browse/DERBY-6114 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.2.2, 10.10.1.1 Environment: Derby head of 10.10 branch. ubuntu3 slave on builds.apache.org. Java SE 7u4, 64-bit. java.vendor=Oracle Corporation java.runtime.version=1.7.0_04-b20 os.name=Linux os.arch=amd64 os.version=3.2.0-38-generic Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: backport-10.10.diff, derby-6114-1a-purge.diff, derby.log, error-stacktrace.out Seen twice in a row in https://builds.apache.org/job/Derby-10.10-suites.All/ : junit-lowmem: [junit] Running org.apache.derbyTesting.functionTests.tests.memory._Suite [junit] Exception in thread DRDAConnThread_11 java.lang.OutOfMemoryError: GC overhead limit exceeded [junit] at java.util.Properties$LineReader.init(Properties.java:405) [junit] at java.util.Properties.load(Properties.java:341) [junit] at java.util.PropertyResourceBundle.init(PropertyResourceBundle.java:130) [junit] at java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2610) [junit] at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1436) [junit] at java.util.ResourceBundle.findBundle(ResourceBundle.java:1400) [junit] at java.util.ResourceBundle.findBundle(ResourceBundle.java:1354) [junit] at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1296) [junit] at java.util.ResourceBundle.getBundle(ResourceBundle.java:796) [junit] at org.apache.derby.iapi.services.i18n.MessageService.getBundleWithEnDefault(MessageService.java:318) [junit] at org.apache.derby.iapi.services.i18n.MessageService.getBundleForLocale(MessageService.java:53) [junit] at org.apache.derby.iapi.services.i18n.MessageService.getBundle(MessageService.java:302) [junit] at org.apache.derby.iapi.services.i18n.MessageService.getCompleteMessage(MessageService.java:97) [junit] at org.apache.derby.iapi.error.SQLWarningFactory.newSQLWarning(SQLWarningFactory.java:97) [junit] at org.apache.derby.iapi.error.SQLWarningFactory.newSQLWarning(SQLWarningFactory.java:50) [junit] at org.apache.derby.iapi.jdbc.BrokeredConnection.statementHoldabilityCheck(BrokeredConnection.java:736) [junit] at org.apache.derby.iapi.jdbc.BrokeredConnection.prepareStatement(BrokeredConnection.java:690) [junit] at org.apache.derby.impl.drda.DRDAStatement.prepare(DRDAStatement.java:669) [junit] at org.apache.derby.impl.drda.DRDAStatement.explicitPrepare(DRDAStatement.java:630) [junit] at org.apache.derby.impl.drda.DRDAConnThread.parsePRPSQLSTT(DRDAConnThread.java:3912) [junit] at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:811) [junit] at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:295) [junit] Tests run: 67, Failures: 0, Errors: 1, Time elapsed: 1,571.059 sec [junit] Test org.apache.derbyTesting.functionTests.tests.memory._Suite FAILED -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-1997) Misleading text in WwdEmbedded demo source file for Working With Derby
[ https://issues.apache.org/jira/browse/DERBY-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13693886#comment-13693886 ] ASF subversion and git services commented on DERBY-1997: Commit 1496870 from [~dyret] [ https://svn.apache.org/r1496870 ] DERBY-1997: Remove custom exception printing methods and replace with printStackTrace as suggested Misleading text in WwdEmbedded demo source file for Working With Derby -- Key: DERBY-1997 URL: https://issues.apache.org/jira/browse/DERBY-1997 Project: Derby Issue Type: Bug Components: Demos/Scripts, Documentation Affects Versions: 10.2.1.6 Reporter: Kim Haase Priority: Minor Labels: derby_triage10_5_2 Attachments: vcs-diff3523819486798216332.patch, vcs-diff7276709987551559550.patch I'm making some minor fixes to the Working With Derby manual (DERBY-1948, DERBY-1972). The description of the WwdEmbedded.java program in the HTML generated from the file rwwdactivity3.dita (http://db.apache.org/derby/docs/dev/workingwithderby/) contains the following paragraph: DERBY EXCEPTION REPORTING CLASSES: The two methods at the end of the file, errorPrint and SQLExceptionPrint, are generic exception reporting routines that can be used with any JDBC program. This type of exception handling is required because often multiple exceptions (SQLException) are chained together then thrown. A while loop is used to report on each error in the chain. These classes are used by calling the errorPrint method from the catch block of the code that accesses the database. The introductory text DERBY EXCEPTION REPORTING CLASSES is keyed to a comment with the same text in the DERBY_HOME/demo/programs/workingwithderby/WwdEmbedded.java program: // ## DERBY EXCEPTION REPORTING CLASSES ## /*** Exception reporting methods ** with special handling of SQLExceptions ***/ The problem is that there are no Derby exception reporting classes, only methods, as far as I can tell. The use of the term CLASSES is likely to confuse any users not well acquainted with Java (one of the target audiences of this manual). It would be great if someone could change CLASSES to METHODS in the WwdEmbedded.java file so that I can make the corresponding fix to the rwwdactivity3.dita file. I would also have to correct the confusing last sentence of the paragraph; I think it would make more sense to say, The program starts this process by calling the errorPrint method from the catch block of the code that accesses the database. (I can't just change classes to methods because errorPrint *is* one of the methods. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6273) NullPointerException when using more than one parameter in COALESCE
[ https://issues.apache.org/jira/browse/DERBY-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13694061#comment-13694061 ] ASF subversion and git services commented on DERBY-6273: Commit 1496996 from [~knutanders] [ https://svn.apache.org/r1496996 ] DERBY-6273: NullPointerException when using more than one parameter in COALESCE Merged revision 1496837 from trunk. NullPointerException when using more than one parameter in COALESCE --- Key: DERBY-6273 URL: https://issues.apache.org/jira/browse/DERBY-6273 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.10.1.1 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Attachments: derby-6273-01-a.diff Calls to COALESCE fail with NullPointerExceptions if there are multiple ? parameters: ij version 10.10 ij connect 'jdbc:derby:memory:db;create=true'; ij prepare ps as 'values coalesce(?,?,1)'; ERROR XJ001: Java exception: ': java.lang.NullPointerException'. (errorCode = 0) java.lang.NullPointerException at org.apache.derby.impl.sql.compile.ParameterNode.generateExpression(Unknown Source) at org.apache.derby.impl.sql.compile.CoalesceFunctionNode.generateExpression(Unknown Source) at org.apache.derby.impl.sql.compile.ResultColumn.generateExpression(Unknown Source) at org.apache.derby.impl.sql.compile.ResultColumnList.generateCore(Unknown Source) at org.apache.derby.impl.sql.compile.ResultColumnList.generate(Unknown Source) at org.apache.derby.impl.sql.compile.RowResultSetNode.generate(Unknown Source) at org.apache.derby.impl.sql.compile.ScrollInsensitiveResultSetNode.generate(Unknown Source) at org.apache.derby.impl.sql.compile.CursorNode.generate(Unknown Source) at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown Source) at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.apache.derby.impl.tools.ij.ij.PrepareStatement(Unknown Source) at org.apache.derby.impl.tools.ij.ij.ijStatement(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown Source) at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source) at org.apache.derby.impl.tools.ij.Main.go(Unknown Source) at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source) at org.apache.derby.impl.tools.ij.Main.main(Unknown Source) at org.apache.derby.tools.ij.main(Unknown Source) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6264) Improve test coverage of org.apache.derby.iapi.db.PropertyInfo
[ https://issues.apache.org/jira/browse/DERBY-6264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13694463#comment-13694463 ] ASF subversion and git services commented on DERBY-6264: Commit 1497205 from [~bryanpendleton] [ https://svn.apache.org/r1497205 ] DERBY-6264: Improve test coverage of org.apache.derby.iapi.db.PropertyInfo This patch was contributed by Ahsan Shamsudeen (ahsan dot competition at gmail dot com) This patch removes several unused methods from the PropertyInfo class. These classes were part of the original Cloudscape SQL-J language many years ago, but are not used in Derby. Removing the unused methods simplifies the class. Should we ever decide to revive the features of the SQL-J language, we can recover these methods from the older versions of the class in Subversion. Improve test coverage of org.apache.derby.iapi.db.PropertyInfo -- Key: DERBY-6264 URL: https://issues.apache.org/jira/browse/DERBY-6264 Project: Derby Issue Type: Sub-task Components: Test Reporter: Bryan Pendleton Assignee: ahsan shamsudeen Priority: Minor Attachments: DERBY-6264.patch According to the coverage reports, only 1 of the 5 methods in org.apache.derby.iapi.db.PropertyInfo is exercised by the Derby regression tests. This sub-task is to improve that test coverage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-673) Get rid of the NodeFactory
[ https://issues.apache.org/jira/browse/DERBY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13694549#comment-13694549 ] ASF subversion and git services commented on DERBY-673: --- Commit 1497230 from [~dagw] [ https://svn.apache.org/r1497230 ] DERBY-673: Get rid of the NodeFactory Remove an erroneously re-introduced public keyword from method getParameterTypes. This removes a FindBugs warning about exposing internal representation by returning reference to mutable object. Get rid of the NodeFactory -- Key: DERBY-673 URL: https://issues.apache.org/jira/browse/DERBY-673 Project: Derby Issue Type: Improvement Components: SQL Reporter: Rick Hillegas Assignee: Dag H. Wanvik Labels: derby_triage10_11 Attachments: derby-673-1.diff.gz, derby-673-1.status, derby-673-2.diff.gz, derby-673-2.status, derby-673-3.diff.gz, derby-673-3.status, derby-673-fixcomments.diff, derby-673-typesafe-lists-1.diff, derby-673-typesafe-lists-1.status, nodefactory-31.status, nodefactory-31.zip This piece of code once had a purpose in life. It was one of the double-joints which allowed cloudscape to ship with and without compiler support for the synchronization language. Synchronization has been removed. If we want to plug in optional language components, I think there are better ways to do this. The NodeFactory turned into a big, sprawling piece of code. At some point this code was slimmed down by telescoping all of its factory methods into a couple unwieldly, weakly-typed overloads backed by cumbersome logic in the actual node constructors. I would like to reintroduce strongly typed node constructors which the parser can call directly. This will make node generation easier to read and less brittle and it will get rid of the now useless NodeFactory class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6211) Make Optimizer trace logic pluggable.
[ https://issues.apache.org/jira/browse/DERBY-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13695006#comment-13695006 ] ASF subversion and git services commented on DERBY-6211: Commit 1497537 from [~rhillegas] [ https://svn.apache.org/r1497537 ] DERBY-6211: Fix NPE in xml-based optimizer tracing; committing derby-6211-08-aa-fixNPE.diff. Make Optimizer trace logic pluggable. - Key: DERBY-6211 URL: https://issues.apache.org/jira/browse/DERBY-6211 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.11.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Labels: derby_triage10_11 Attachments: derby-6211-01-aa-createPlugin.diff, derby-6211-02-aa-cleanup.diff, derby-6211-02-ab-cleanup.diff, derby-6211-03-aa-customTracer.diff, derby-6211-04-aa-moveOptimizerTracerToEngineJar.diff, derby-6211-05-aa-xmlOptimizerTracer.diff, derby-6211-06-ab-packageProtect-XMLOptTrace.diff, derby-6211-07-aa-useSchemaQualifiedNamesInSummaries.diff, derby-6211-07-ab-useSchemaQualifiedNamesInSummaries.diff, derby-6211-08-aa-fixNPE.diff Right now the trace logic in the optimizer is hard-coded to produce a stream of diagnostics. It would be good to be able to plug alternative trace logic into the optimizer. This would make the following possible: 1) Plug in trace logic which produces formats which are easier to study and which can be analyzed mechanically. E.g., xml formatted output. 2) Plug in trace logic which can be used during unit testing to verify that the optimizer has picked the right plan. Over time this might make it easier to migrate canon-based tests to assertion-based tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-673) Get rid of the NodeFactory
[ https://issues.apache.org/jira/browse/DERBY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13695255#comment-13695255 ] ASF subversion and git services commented on DERBY-673: --- Commit 1497644 from [~dagw] [ https://svn.apache.org/r1497644 ] DERBY-673: Get rid of the NodeFactory Patch derby-673-typesafe-lists-2, which introduces generics to the lists based on QueryTreeNodeVector. I also let the latter implement the Iterable interface, which opens up for using Java 6 foreach syntax in many cases. The patch makes use of this. Together, these changes enables many casts to be eliminated and code clarification in the compiler implementation. It also removes most -Xlint warnings from impl/sql/compile classes, so it should be ready to run with full lint. Diffstat summary: 63 files changed, 854 insertions(+), 1236 deletions(-) Get rid of the NodeFactory -- Key: DERBY-673 URL: https://issues.apache.org/jira/browse/DERBY-673 Project: Derby Issue Type: Improvement Components: SQL Reporter: Rick Hillegas Assignee: Dag H. Wanvik Labels: derby_triage10_11 Attachments: derby-673-1.diff.gz, derby-673-1.status, derby-673-2.diff.gz, derby-673-2.status, derby-673-3.diff.gz, derby-673-3.status, derby-673-fixcomments.diff, derby-673-typesafe-lists-1.diff, derby-673-typesafe-lists-1.status, derby-673-typesafe-lists-2.diff.gz, derby-673-typesafe-lists-2.status, nodefactory-31.status, nodefactory-31.zip This piece of code once had a purpose in life. It was one of the double-joints which allowed cloudscape to ship with and without compiler support for the synchronization language. Synchronization has been removed. If we want to plug in optional language components, I think there are better ways to do this. The NodeFactory turned into a big, sprawling piece of code. At some point this code was slimmed down by telescoping all of its factory methods into a couple unwieldly, weakly-typed overloads backed by cumbersome logic in the actual node constructors. I would like to reintroduce strongly typed node constructors which the parser can call directly. This will make node generation easier to read and less brittle and it will get rid of the now useless NodeFactory class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-673) Get rid of the NodeFactory
[ https://issues.apache.org/jira/browse/DERBY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13695409#comment-13695409 ] ASF subversion and git services commented on DERBY-673: --- Commit 1497742 from [~dagw] [ https://svn.apache.org/r1497742 ] DERBY-673: Get rid of the NodeFactory Followup fix to patch derby-673-typesafe-lists-2. The patch introduced an issue causing ConcurrentModificationException. Roll back that change. Get rid of the NodeFactory -- Key: DERBY-673 URL: https://issues.apache.org/jira/browse/DERBY-673 Project: Derby Issue Type: Improvement Components: SQL Reporter: Rick Hillegas Assignee: Dag H. Wanvik Labels: derby_triage10_11 Attachments: derby-673-1.diff.gz, derby-673-1.status, derby-673-2.diff.gz, derby-673-2.status, derby-673-3.diff.gz, derby-673-3.status, derby-673-fixcomments.diff, derby-673-typesafe-lists-1.diff, derby-673-typesafe-lists-1.status, derby-673-typesafe-lists-2.diff.gz, derby-673-typesafe-lists-2.status, nodefactory-31.status, nodefactory-31.zip This piece of code once had a purpose in life. It was one of the double-joints which allowed cloudscape to ship with and without compiler support for the synchronization language. Synchronization has been removed. If we want to plug in optional language components, I think there are better ways to do this. The NodeFactory turned into a big, sprawling piece of code. At some point this code was slimmed down by telescoping all of its factory methods into a couple unwieldly, weakly-typed overloads backed by cumbersome logic in the actual node constructors. I would like to reintroduce strongly typed node constructors which the parser can call directly. This will make node generation easier to read and less brittle and it will get rid of the now useless NodeFactory class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-673) Get rid of the NodeFactory
[ https://issues.apache.org/jira/browse/DERBY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13695442#comment-13695442 ] ASF subversion and git services commented on DERBY-673: --- Commit 1497767 from [~dagw] [ https://svn.apache.org/r1497767 ] DERBY-673: Get rid of the NodeFactory Followup fix to patch derby-673-typesafe-lists-2. The patch introduced a bug in FromSubquery: wrong loop upper bound. Roll back that change. Get rid of the NodeFactory -- Key: DERBY-673 URL: https://issues.apache.org/jira/browse/DERBY-673 Project: Derby Issue Type: Improvement Components: SQL Reporter: Rick Hillegas Assignee: Dag H. Wanvik Labels: derby_triage10_11 Attachments: derby-673-1.diff.gz, derby-673-1.status, derby-673-2.diff.gz, derby-673-2.status, derby-673-3.diff.gz, derby-673-3.status, derby-673-fixcomments.diff, derby-673-typesafe-lists-1.diff, derby-673-typesafe-lists-1.status, derby-673-typesafe-lists-2.diff.gz, derby-673-typesafe-lists-2.status, nodefactory-31.status, nodefactory-31.zip This piece of code once had a purpose in life. It was one of the double-joints which allowed cloudscape to ship with and without compiler support for the synchronization language. Synchronization has been removed. If we want to plug in optional language components, I think there are better ways to do this. The NodeFactory turned into a big, sprawling piece of code. At some point this code was slimmed down by telescoping all of its factory methods into a couple unwieldly, weakly-typed overloads backed by cumbersome logic in the actual node constructors. I would like to reintroduce strongly typed node constructors which the parser can call directly. This will make node generation easier to read and less brittle and it will get rid of the now useless NodeFactory class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-3790) Investigate if request for update statistics can be skipped for certain kind of indexes, one instance may be unique indexes based on one column.
[ https://issues.apache.org/jira/browse/DERBY-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13695633#comment-13695633 ] ASF subversion and git services commented on DERBY-3790: Commit 1497868 from [~mamtas] [ https://svn.apache.org/r1497868 ] DERBY-5680( indexStat daemon processing tables over and over even when there are no changes in the tables ) Backporting the 3 commits that went in for DERBY-5680 to 10.8. The 3 commits were 1340549, 1341622, 1341629. The first two commits were easy to backport using svn merge command but the third commit 1341629 ran into conflicts. For that backport, hand made the changes since there were not too many changes. The changes for this jira has added a new property derby.storage.indexStats.debug.keepDisposableStats. The intention of the property is that if the property is set to true, we do not delete the orphaned/disposable stats. If the property is set to false, the orphaned/disposable stats will get dropped by the index stats daemon. Currently known reasons for orphaned/disposable stats are 1)DERBY-5681(When a foreign key constraint on a table is dropped, the associated statistics row for the conglomerate is not removed). Fix for this has been backported all the way to 10.3 2)DERBY-3790(Investigate if request for update statistics can be skipped for certain kind of indexes, one instance may be unique indexes based on one column.) Fix for this is in 10.9 and higher A junit test was added for this new property but it went in as part of DERBY-3790. The name of the junit test is store.KeepDisposableStatsPropertyTest. Had to make changes to this test to backport it to 10.8 but without the fix for DEBRY-3790 and with the absence of drop statistics procedure, the test really does not make much sense for 10.8 codeline. The test uses drop statistics procedure and it is mainly testing DERBY-3790 to make sure that the orphaned stats are being deleted or left behind based on whether the property is set to true or false. But since we do not have drop statistics procedure and we do not have DERBY-3790 fixed in 10.8, we can't really meaningfully run the KeepDisposableStatsPropertyTest in 10.8. In any case, I have changed the test so that atleast it will not fail in 10.8 but it is not able to truly test the property. May be we can test this property through upgrade suite where we will create orphaned stats because of DERBY-5681 on older releases and we will find that when the property is set to true, even after upgrade, we will have orphaned stats but when property is set to false, after upgrade, orphaned stats are deleted. Investigate if request for update statistics can be skipped for certain kind of indexes, one instance may be unique indexes based on one column. Key: DERBY-3790 URL: https://issues.apache.org/jira/browse/DERBY-3790 Project: Derby Issue Type: Improvement Components: Store Affects Versions: 10.5.1.1 Reporter: Mamta A. Satoor Assignee: Kristian Waagan Fix For: 10.9.1.0 Attachments: derby-3790-1a-skip_stats_scui.diff, derby-3790-1b-skip_stats_scui.diff, derby-3790-1c-skip_stats_scui.diff, derby-3790-2a-minor_test_improvements.diff DERBY-269 provided a manual way to update the statisitcs. There was some discussion in that jira entry for possibly optimizing the cases where there is no need to update the statistics. I will enter the related comments from that jira entry here for reference. ** Knut Anders Hatlen - 18/Jul/08 12:39 AM If I have understood correctly, unique indexes always have up to date cardinality statistics because cardinality == row count. If that's the case, one possible optimization is to skip the unique indexes when SYSCS_UPDATE_STATISTICS is called. ** ** Mike Matrigali - 18/Jul/08 09:48 AM is the cardinality of a unique index 1 or is it row count? It is also more complicated than just skipping unique indexes, it depends on the number of columns in the index because in a multi-column index, multiple cardinalities are calculated. So for instance on an index on columns A,B,C there are actually 3 cardinalities calculated: A A,B A,B,C I agree that the calculation of cardinality of A,B,C could/should be short circuited for a unique index. ** ** Knut Anders Hatlen - 18/Jul/08 03:25 PM Mike, It looks to me as if the cardinality is the number of unique values, so I think the cardinality of a unique index is equal to its row count (for the full key, that is).
[jira] [Commented] (DERBY-5680) indexStat daemon processing tables over and over even when there are no changes in the tables
[
https://issues.apache.org/jira/browse/DERBY-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13695629#comment-13695629
]
ASF subversion and git services commented on DERBY-5680:
Commit 1497868 from [~mamtas]
[ https://svn.apache.org/r1497868 ]
DERBY-5680( indexStat daemon processing tables over and over even when there
are no changes in the tables )
Backporting the 3 commits that went in for DERBY-5680 to 10.8. The 3 commits
were 1340549, 1341622, 1341629. The first two commits were easy to backport
using svn merge command but the third commit 1341629 ran into conflicts. For
that backport, hand made the changes since there were not too many changes.
The changes for this jira has added a new property
derby.storage.indexStats.debug.keepDisposableStats. The intention of the
property is that if the property is set to true, we do not delete the
orphaned/disposable stats. If the property is set to false, the
orphaned/disposable stats will get dropped by the index stats daemon. Currently
known reasons for orphaned/disposable stats are
1)DERBY-5681(When a foreign key constraint on a table is dropped, the
associated statistics row for the conglomerate is not removed). Fix for this
has been backported all the way to 10.3
2)DERBY-3790(Investigate if request for update statistics can be skipped for
certain kind of indexes, one instance may be unique indexes based on one
column.) Fix for this is in 10.9 and higher
A junit test was added for this new property but it went in as part of
DERBY-3790. The name of the junit test is
store.KeepDisposableStatsPropertyTest. Had to make changes to this test to
backport it to 10.8 but without the fix for DEBRY-3790 and with the absence of
drop statistics procedure, the test really does not make much sense for 10.8
codeline. The test uses drop statistics procedure and it is mainly testing
DERBY-3790 to make sure that the orphaned stats are being deleted or left
behind based on whether the property is set to true or false. But since we do
not have drop statistics procedure and we do not have DERBY-3790 fixed in 10.8,
we can't really meaningfully run the KeepDisposableStatsPropertyTest in 10.8.
In any case, I have changed the test so that atleast it will not fail in 10.8
but it is not able to truly test the property. May be we can test this property
through upgrade suite where we will create orphaned stats because of DERBY-5681
on older releases and we will find that when the property is set to true, even
after upgrade, we will have orphaned stats but when property is set to false,
after upgrade, orphaned stats are deleted.
indexStat daemon processing tables over and over even when there are no
changes in the tables
-
Key: DERBY-5680
URL: https://issues.apache.org/jira/browse/DERBY-5680
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.8.2.2, 10.9.1.0
Reporter: Brett Bergquist
Assignee: Kristian Waagan
Fix For: 10.9.1.0
Attachments: derby-5680-1a-drop_orphaned_stats.diff,
derby-5680-1b-remove_disposable_stats.diff,
derby-5680-2a-remove_redundant_check.diff,
derby-5680-3a-rename_debug_property.diff,
DERBY5680_backportTo108_patch1_diff.txt,
DERBY5680_backportTo108_patch1_stat.txt
I think there is something wrong with the indexStats.
The problem happens on many tables in the database.
None of these tables are changing however, no inserts or deletes or updates.
They are being queried, however.
Here is one such table.
Here is the statistics for this table:
Table (Index) 2 3
ACCOUNTTABLE_CONFIG_BUNDLE (SQL081029110443810) numunique= 38390
numrows= 38390 2012-03-30 13:00:26.84
ACCOUNTTABLE_CONFIG_BUNDLE (SQL100922215819290) numunique= 38390
numrows= 38390 2012-03-30 13:00:26.917
There are in fact 38390 rows in the table.
Here is some of the indexStat trace:
Fri Mar 30 12:47:12 EDT 2012 Thread[DRDAConnThread_43,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: update scheduled,
reason=[t-est=38390, i-est=2355 = cmp=2.7912562815443245] (queueSize=12)
Fri Mar 30 12:47:48 EDT 2012 Thread[index-stat-thread,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: wrote stats for index
SQL081029110443810 (fc33890d-011d-491f-3d8c-376d74d3): rows=38390,
card=[38390]
Fri Mar 30 12:47:48 EDT 2012 Thread[index-stat-thread,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: wrote stats for index
SQL100922215819290 (75608675-012b-3c38-b55c-43ea6398): rows=38390,
card=[38390]
Fri Mar 30 12:47:48 EDT 2012 Thread[index-stat-thread,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: scan
[jira] [Commented] (DERBY-3790) Investigate if request for update statistics can be skipped for certain kind of indexes, one instance may be unique indexes based on one column.
[ https://issues.apache.org/jira/browse/DERBY-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13695632#comment-13695632 ] ASF subversion and git services commented on DERBY-3790: Commit 1497868 from [~mamtas] [ https://svn.apache.org/r1497868 ] DERBY-5680( indexStat daemon processing tables over and over even when there are no changes in the tables ) Backporting the 3 commits that went in for DERBY-5680 to 10.8. The 3 commits were 1340549, 1341622, 1341629. The first two commits were easy to backport using svn merge command but the third commit 1341629 ran into conflicts. For that backport, hand made the changes since there were not too many changes. The changes for this jira has added a new property derby.storage.indexStats.debug.keepDisposableStats. The intention of the property is that if the property is set to true, we do not delete the orphaned/disposable stats. If the property is set to false, the orphaned/disposable stats will get dropped by the index stats daemon. Currently known reasons for orphaned/disposable stats are 1)DERBY-5681(When a foreign key constraint on a table is dropped, the associated statistics row for the conglomerate is not removed). Fix for this has been backported all the way to 10.3 2)DERBY-3790(Investigate if request for update statistics can be skipped for certain kind of indexes, one instance may be unique indexes based on one column.) Fix for this is in 10.9 and higher A junit test was added for this new property but it went in as part of DERBY-3790. The name of the junit test is store.KeepDisposableStatsPropertyTest. Had to make changes to this test to backport it to 10.8 but without the fix for DEBRY-3790 and with the absence of drop statistics procedure, the test really does not make much sense for 10.8 codeline. The test uses drop statistics procedure and it is mainly testing DERBY-3790 to make sure that the orphaned stats are being deleted or left behind based on whether the property is set to true or false. But since we do not have drop statistics procedure and we do not have DERBY-3790 fixed in 10.8, we can't really meaningfully run the KeepDisposableStatsPropertyTest in 10.8. In any case, I have changed the test so that atleast it will not fail in 10.8 but it is not able to truly test the property. May be we can test this property through upgrade suite where we will create orphaned stats because of DERBY-5681 on older releases and we will find that when the property is set to true, even after upgrade, we will have orphaned stats but when property is set to false, after upgrade, orphaned stats are deleted. Investigate if request for update statistics can be skipped for certain kind of indexes, one instance may be unique indexes based on one column. Key: DERBY-3790 URL: https://issues.apache.org/jira/browse/DERBY-3790 Project: Derby Issue Type: Improvement Components: Store Affects Versions: 10.5.1.1 Reporter: Mamta A. Satoor Assignee: Kristian Waagan Fix For: 10.9.1.0 Attachments: derby-3790-1a-skip_stats_scui.diff, derby-3790-1b-skip_stats_scui.diff, derby-3790-1c-skip_stats_scui.diff, derby-3790-2a-minor_test_improvements.diff DERBY-269 provided a manual way to update the statisitcs. There was some discussion in that jira entry for possibly optimizing the cases where there is no need to update the statistics. I will enter the related comments from that jira entry here for reference. ** Knut Anders Hatlen - 18/Jul/08 12:39 AM If I have understood correctly, unique indexes always have up to date cardinality statistics because cardinality == row count. If that's the case, one possible optimization is to skip the unique indexes when SYSCS_UPDATE_STATISTICS is called. ** ** Mike Matrigali - 18/Jul/08 09:48 AM is the cardinality of a unique index 1 or is it row count? It is also more complicated than just skipping unique indexes, it depends on the number of columns in the index because in a multi-column index, multiple cardinalities are calculated. So for instance on an index on columns A,B,C there are actually 3 cardinalities calculated: A A,B A,B,C I agree that the calculation of cardinality of A,B,C could/should be short circuited for a unique index. ** ** Knut Anders Hatlen - 18/Jul/08 03:25 PM Mike, It looks to me as if the cardinality is the number of unique values, so I think the cardinality of a unique index is equal to its row count (for the full key, that is).
[jira] [Commented] (DERBY-3790) Investigate if request for update statistics can be skipped for certain kind of indexes, one instance may be unique indexes based on one column.
[ https://issues.apache.org/jira/browse/DERBY-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13695634#comment-13695634 ] ASF subversion and git services commented on DERBY-3790: Commit 1497868 from [~mamtas] [ https://svn.apache.org/r1497868 ] DERBY-5680( indexStat daemon processing tables over and over even when there are no changes in the tables ) Backporting the 3 commits that went in for DERBY-5680 to 10.8. The 3 commits were 1340549, 1341622, 1341629. The first two commits were easy to backport using svn merge command but the third commit 1341629 ran into conflicts. For that backport, hand made the changes since there were not too many changes. The changes for this jira has added a new property derby.storage.indexStats.debug.keepDisposableStats. The intention of the property is that if the property is set to true, we do not delete the orphaned/disposable stats. If the property is set to false, the orphaned/disposable stats will get dropped by the index stats daemon. Currently known reasons for orphaned/disposable stats are 1)DERBY-5681(When a foreign key constraint on a table is dropped, the associated statistics row for the conglomerate is not removed). Fix for this has been backported all the way to 10.3 2)DERBY-3790(Investigate if request for update statistics can be skipped for certain kind of indexes, one instance may be unique indexes based on one column.) Fix for this is in 10.9 and higher A junit test was added for this new property but it went in as part of DERBY-3790. The name of the junit test is store.KeepDisposableStatsPropertyTest. Had to make changes to this test to backport it to 10.8 but without the fix for DEBRY-3790 and with the absence of drop statistics procedure, the test really does not make much sense for 10.8 codeline. The test uses drop statistics procedure and it is mainly testing DERBY-3790 to make sure that the orphaned stats are being deleted or left behind based on whether the property is set to true or false. But since we do not have drop statistics procedure and we do not have DERBY-3790 fixed in 10.8, we can't really meaningfully run the KeepDisposableStatsPropertyTest in 10.8. In any case, I have changed the test so that atleast it will not fail in 10.8 but it is not able to truly test the property. May be we can test this property through upgrade suite where we will create orphaned stats because of DERBY-5681 on older releases and we will find that when the property is set to true, even after upgrade, we will have orphaned stats but when property is set to false, after upgrade, orphaned stats are deleted. Investigate if request for update statistics can be skipped for certain kind of indexes, one instance may be unique indexes based on one column. Key: DERBY-3790 URL: https://issues.apache.org/jira/browse/DERBY-3790 Project: Derby Issue Type: Improvement Components: Store Affects Versions: 10.5.1.1 Reporter: Mamta A. Satoor Assignee: Kristian Waagan Fix For: 10.9.1.0 Attachments: derby-3790-1a-skip_stats_scui.diff, derby-3790-1b-skip_stats_scui.diff, derby-3790-1c-skip_stats_scui.diff, derby-3790-2a-minor_test_improvements.diff DERBY-269 provided a manual way to update the statisitcs. There was some discussion in that jira entry for possibly optimizing the cases where there is no need to update the statistics. I will enter the related comments from that jira entry here for reference. ** Knut Anders Hatlen - 18/Jul/08 12:39 AM If I have understood correctly, unique indexes always have up to date cardinality statistics because cardinality == row count. If that's the case, one possible optimization is to skip the unique indexes when SYSCS_UPDATE_STATISTICS is called. ** ** Mike Matrigali - 18/Jul/08 09:48 AM is the cardinality of a unique index 1 or is it row count? It is also more complicated than just skipping unique indexes, it depends on the number of columns in the index because in a multi-column index, multiple cardinalities are calculated. So for instance on an index on columns A,B,C there are actually 3 cardinalities calculated: A A,B A,B,C I agree that the calculation of cardinality of A,B,C could/should be short circuited for a unique index. ** ** Knut Anders Hatlen - 18/Jul/08 03:25 PM Mike, It looks to me as if the cardinality is the number of unique values, so I think the cardinality of a unique index is equal to its row count (for the full key, that is).
[jira] [Commented] (DERBY-5680) indexStat daemon processing tables over and over even when there are no changes in the tables
[
https://issues.apache.org/jira/browse/DERBY-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13695630#comment-13695630
]
ASF subversion and git services commented on DERBY-5680:
Commit 1497868 from [~mamtas]
[ https://svn.apache.org/r1497868 ]
DERBY-5680( indexStat daemon processing tables over and over even when there
are no changes in the tables )
Backporting the 3 commits that went in for DERBY-5680 to 10.8. The 3 commits
were 1340549, 1341622, 1341629. The first two commits were easy to backport
using svn merge command but the third commit 1341629 ran into conflicts. For
that backport, hand made the changes since there were not too many changes.
The changes for this jira has added a new property
derby.storage.indexStats.debug.keepDisposableStats. The intention of the
property is that if the property is set to true, we do not delete the
orphaned/disposable stats. If the property is set to false, the
orphaned/disposable stats will get dropped by the index stats daemon. Currently
known reasons for orphaned/disposable stats are
1)DERBY-5681(When a foreign key constraint on a table is dropped, the
associated statistics row for the conglomerate is not removed). Fix for this
has been backported all the way to 10.3
2)DERBY-3790(Investigate if request for update statistics can be skipped for
certain kind of indexes, one instance may be unique indexes based on one
column.) Fix for this is in 10.9 and higher
A junit test was added for this new property but it went in as part of
DERBY-3790. The name of the junit test is
store.KeepDisposableStatsPropertyTest. Had to make changes to this test to
backport it to 10.8 but without the fix for DEBRY-3790 and with the absence of
drop statistics procedure, the test really does not make much sense for 10.8
codeline. The test uses drop statistics procedure and it is mainly testing
DERBY-3790 to make sure that the orphaned stats are being deleted or left
behind based on whether the property is set to true or false. But since we do
not have drop statistics procedure and we do not have DERBY-3790 fixed in 10.8,
we can't really meaningfully run the KeepDisposableStatsPropertyTest in 10.8.
In any case, I have changed the test so that atleast it will not fail in 10.8
but it is not able to truly test the property. May be we can test this property
through upgrade suite where we will create orphaned stats because of DERBY-5681
on older releases and we will find that when the property is set to true, even
after upgrade, we will have orphaned stats but when property is set to false,
after upgrade, orphaned stats are deleted.
indexStat daemon processing tables over and over even when there are no
changes in the tables
-
Key: DERBY-5680
URL: https://issues.apache.org/jira/browse/DERBY-5680
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.8.2.2, 10.9.1.0
Reporter: Brett Bergquist
Assignee: Kristian Waagan
Fix For: 10.9.1.0
Attachments: derby-5680-1a-drop_orphaned_stats.diff,
derby-5680-1b-remove_disposable_stats.diff,
derby-5680-2a-remove_redundant_check.diff,
derby-5680-3a-rename_debug_property.diff,
DERBY5680_backportTo108_patch1_diff.txt,
DERBY5680_backportTo108_patch1_stat.txt
I think there is something wrong with the indexStats.
The problem happens on many tables in the database.
None of these tables are changing however, no inserts or deletes or updates.
They are being queried, however.
Here is one such table.
Here is the statistics for this table:
Table (Index) 2 3
ACCOUNTTABLE_CONFIG_BUNDLE (SQL081029110443810) numunique= 38390
numrows= 38390 2012-03-30 13:00:26.84
ACCOUNTTABLE_CONFIG_BUNDLE (SQL100922215819290) numunique= 38390
numrows= 38390 2012-03-30 13:00:26.917
There are in fact 38390 rows in the table.
Here is some of the indexStat trace:
Fri Mar 30 12:47:12 EDT 2012 Thread[DRDAConnThread_43,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: update scheduled,
reason=[t-est=38390, i-est=2355 = cmp=2.7912562815443245] (queueSize=12)
Fri Mar 30 12:47:48 EDT 2012 Thread[index-stat-thread,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: wrote stats for index
SQL081029110443810 (fc33890d-011d-491f-3d8c-376d74d3): rows=38390,
card=[38390]
Fri Mar 30 12:47:48 EDT 2012 Thread[index-stat-thread,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: wrote stats for index
SQL100922215819290 (75608675-012b-3c38-b55c-43ea6398): rows=38390,
card=[38390]
Fri Mar 30 12:47:48 EDT 2012 Thread[index-stat-thread,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: scan
[jira] [Commented] (DERBY-5681) When a foreign key constraint on a table is dropped, the associated statistics row for the conglomerate is not removed
[
https://issues.apache.org/jira/browse/DERBY-5681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13695636#comment-13695636
]
ASF subversion and git services commented on DERBY-5681:
Commit 1497868 from [~mamtas]
[ https://svn.apache.org/r1497868 ]
DERBY-5680( indexStat daemon processing tables over and over even when there
are no changes in the tables )
Backporting the 3 commits that went in for DERBY-5680 to 10.8. The 3 commits
were 1340549, 1341622, 1341629. The first two commits were easy to backport
using svn merge command but the third commit 1341629 ran into conflicts. For
that backport, hand made the changes since there were not too many changes.
The changes for this jira has added a new property
derby.storage.indexStats.debug.keepDisposableStats. The intention of the
property is that if the property is set to true, we do not delete the
orphaned/disposable stats. If the property is set to false, the
orphaned/disposable stats will get dropped by the index stats daemon. Currently
known reasons for orphaned/disposable stats are
1)DERBY-5681(When a foreign key constraint on a table is dropped, the
associated statistics row for the conglomerate is not removed). Fix for this
has been backported all the way to 10.3
2)DERBY-3790(Investigate if request for update statistics can be skipped for
certain kind of indexes, one instance may be unique indexes based on one
column.) Fix for this is in 10.9 and higher
A junit test was added for this new property but it went in as part of
DERBY-3790. The name of the junit test is
store.KeepDisposableStatsPropertyTest. Had to make changes to this test to
backport it to 10.8 but without the fix for DEBRY-3790 and with the absence of
drop statistics procedure, the test really does not make much sense for 10.8
codeline. The test uses drop statistics procedure and it is mainly testing
DERBY-3790 to make sure that the orphaned stats are being deleted or left
behind based on whether the property is set to true or false. But since we do
not have drop statistics procedure and we do not have DERBY-3790 fixed in 10.8,
we can't really meaningfully run the KeepDisposableStatsPropertyTest in 10.8.
In any case, I have changed the test so that atleast it will not fail in 10.8
but it is not able to truly test the property. May be we can test this property
through upgrade suite where we will create orphaned stats because of DERBY-5681
on older releases and we will find that when the property is set to true, even
after upgrade, we will have orphaned stats but when property is set to false,
after upgrade, orphaned stats are deleted.
When a foreign key constraint on a table is dropped, the associated
statistics row for the conglomerate is not removed
--
Key: DERBY-5681
URL: https://issues.apache.org/jira/browse/DERBY-5681
Project: Derby
Issue Type: Bug
Components: SQL, Store
Affects Versions: 10.8.2.2
Reporter: Brett Bergquist
Assignee: Mamta A. Satoor
Fix For: 10.3.3.1, 10.4.2.1, 10.5.3.2, 10.6.2.3, 10.7.1.4,
10.8.3.0, 10.9.1.0
Attachments: derby-5681-3a-test.diff, DERBY5681_patch1_diff.txt,
DERBY5681_patch2_diff.txt
If you drop the foreign key constraint for a table, the statistics row does
not get removed. This affects the indexStat daemon because it now finds
these statistics row which always appear as out of date, causing an update to
be scheduled.
Here is how to get it to happen:
set schema app;
CREATE TABLE TEST_TAB_1
(
ID INTEGER PRIMARY KEY NOT NULL
);
CREATE TABLE TEST_TAB_2
(
ID INTEGER PRIMARY KEY NOT NULL
);
ALTER TABLE TEST_TAB_2
ADD CONSTRAINT TEST_TAB_2_FK_1
FOREIGN KEY (ID) REFERENCES TEST_TAB_1(ID);
insert into app.TEST_TAB_1 values (1);
insert into test_tab_2 values(1);
call syscs_util.syscs_update_statistics('APP', 'TEST_TAB_2', null);
select
c.TABLEID,
c.CONGLOMERATENUMBER,
c.CONGLOMERATENAME,
c.ISINDEX,
c.ISCONSTRAINT,
c.CONGLOMERATEID,
t.TABLEID,
t.TABLENAME,
t.TABLETYPE,
s.STATID,
s.REFERENCEID,
s.TABLEID,
s.CREATIONTIMESTAMP,
s.TYPE,
s.VALID,
s.COLCOUNT,
CAST(STATISTICS AS VARCHAR(40)) as STATISTICS
from sys.SYSCONGLOMERATES c join sys.SYSTABLES t on c.TABLEID = t.TABLEID
join sys.SYSSTATISTICS s on s.TABLEID = t.TABLEID
where t.TABLENAME = 'TEST_TAB_2' and c.ISINDEX = false;
-- At this point there are two statistic rows
TABLEID CONGLOMERATENUMBER CONGLOMERATENAMEISINDEX ISCONSTRAINT
CONGLOMERATEID TABLEID TABLENAME TABLETYPE STATID REFERENCEID
TABLEID CREATIONTIMESTAMP TYPEVALID COLCOUNTSTATISTICS
84490209-0136-6999-c1b4-65089f97348432
[jira] [Commented] (DERBY-5681) When a foreign key constraint on a table is dropped, the associated statistics row for the conglomerate is not removed
[
https://issues.apache.org/jira/browse/DERBY-5681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13695631#comment-13695631
]
ASF subversion and git services commented on DERBY-5681:
Commit 1497868 from [~mamtas]
[ https://svn.apache.org/r1497868 ]
DERBY-5680( indexStat daemon processing tables over and over even when there
are no changes in the tables )
Backporting the 3 commits that went in for DERBY-5680 to 10.8. The 3 commits
were 1340549, 1341622, 1341629. The first two commits were easy to backport
using svn merge command but the third commit 1341629 ran into conflicts. For
that backport, hand made the changes since there were not too many changes.
The changes for this jira has added a new property
derby.storage.indexStats.debug.keepDisposableStats. The intention of the
property is that if the property is set to true, we do not delete the
orphaned/disposable stats. If the property is set to false, the
orphaned/disposable stats will get dropped by the index stats daemon. Currently
known reasons for orphaned/disposable stats are
1)DERBY-5681(When a foreign key constraint on a table is dropped, the
associated statistics row for the conglomerate is not removed). Fix for this
has been backported all the way to 10.3
2)DERBY-3790(Investigate if request for update statistics can be skipped for
certain kind of indexes, one instance may be unique indexes based on one
column.) Fix for this is in 10.9 and higher
A junit test was added for this new property but it went in as part of
DERBY-3790. The name of the junit test is
store.KeepDisposableStatsPropertyTest. Had to make changes to this test to
backport it to 10.8 but without the fix for DEBRY-3790 and with the absence of
drop statistics procedure, the test really does not make much sense for 10.8
codeline. The test uses drop statistics procedure and it is mainly testing
DERBY-3790 to make sure that the orphaned stats are being deleted or left
behind based on whether the property is set to true or false. But since we do
not have drop statistics procedure and we do not have DERBY-3790 fixed in 10.8,
we can't really meaningfully run the KeepDisposableStatsPropertyTest in 10.8.
In any case, I have changed the test so that atleast it will not fail in 10.8
but it is not able to truly test the property. May be we can test this property
through upgrade suite where we will create orphaned stats because of DERBY-5681
on older releases and we will find that when the property is set to true, even
after upgrade, we will have orphaned stats but when property is set to false,
after upgrade, orphaned stats are deleted.
When a foreign key constraint on a table is dropped, the associated
statistics row for the conglomerate is not removed
--
Key: DERBY-5681
URL: https://issues.apache.org/jira/browse/DERBY-5681
Project: Derby
Issue Type: Bug
Components: SQL, Store
Affects Versions: 10.8.2.2
Reporter: Brett Bergquist
Assignee: Mamta A. Satoor
Fix For: 10.3.3.1, 10.4.2.1, 10.5.3.2, 10.6.2.3, 10.7.1.4,
10.8.3.0, 10.9.1.0
Attachments: derby-5681-3a-test.diff, DERBY5681_patch1_diff.txt,
DERBY5681_patch2_diff.txt
If you drop the foreign key constraint for a table, the statistics row does
not get removed. This affects the indexStat daemon because it now finds
these statistics row which always appear as out of date, causing an update to
be scheduled.
Here is how to get it to happen:
set schema app;
CREATE TABLE TEST_TAB_1
(
ID INTEGER PRIMARY KEY NOT NULL
);
CREATE TABLE TEST_TAB_2
(
ID INTEGER PRIMARY KEY NOT NULL
);
ALTER TABLE TEST_TAB_2
ADD CONSTRAINT TEST_TAB_2_FK_1
FOREIGN KEY (ID) REFERENCES TEST_TAB_1(ID);
insert into app.TEST_TAB_1 values (1);
insert into test_tab_2 values(1);
call syscs_util.syscs_update_statistics('APP', 'TEST_TAB_2', null);
select
c.TABLEID,
c.CONGLOMERATENUMBER,
c.CONGLOMERATENAME,
c.ISINDEX,
c.ISCONSTRAINT,
c.CONGLOMERATEID,
t.TABLEID,
t.TABLENAME,
t.TABLETYPE,
s.STATID,
s.REFERENCEID,
s.TABLEID,
s.CREATIONTIMESTAMP,
s.TYPE,
s.VALID,
s.COLCOUNT,
CAST(STATISTICS AS VARCHAR(40)) as STATISTICS
from sys.SYSCONGLOMERATES c join sys.SYSTABLES t on c.TABLEID = t.TABLEID
join sys.SYSSTATISTICS s on s.TABLEID = t.TABLEID
where t.TABLENAME = 'TEST_TAB_2' and c.ISINDEX = false;
-- At this point there are two statistic rows
TABLEID CONGLOMERATENUMBER CONGLOMERATENAMEISINDEX ISCONSTRAINT
CONGLOMERATEID TABLEID TABLENAME TABLETYPE STATID REFERENCEID
TABLEID CREATIONTIMESTAMP TYPEVALID COLCOUNTSTATISTICS
84490209-0136-6999-c1b4-65089f97348432
[jira] [Commented] (DERBY-3790) Investigate if request for update statistics can be skipped for certain kind of indexes, one instance may be unique indexes based on one column.
[ https://issues.apache.org/jira/browse/DERBY-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13695635#comment-13695635 ] ASF subversion and git services commented on DERBY-3790: Commit 1497868 from [~mamtas] [ https://svn.apache.org/r1497868 ] DERBY-5680( indexStat daemon processing tables over and over even when there are no changes in the tables ) Backporting the 3 commits that went in for DERBY-5680 to 10.8. The 3 commits were 1340549, 1341622, 1341629. The first two commits were easy to backport using svn merge command but the third commit 1341629 ran into conflicts. For that backport, hand made the changes since there were not too many changes. The changes for this jira has added a new property derby.storage.indexStats.debug.keepDisposableStats. The intention of the property is that if the property is set to true, we do not delete the orphaned/disposable stats. If the property is set to false, the orphaned/disposable stats will get dropped by the index stats daemon. Currently known reasons for orphaned/disposable stats are 1)DERBY-5681(When a foreign key constraint on a table is dropped, the associated statistics row for the conglomerate is not removed). Fix for this has been backported all the way to 10.3 2)DERBY-3790(Investigate if request for update statistics can be skipped for certain kind of indexes, one instance may be unique indexes based on one column.) Fix for this is in 10.9 and higher A junit test was added for this new property but it went in as part of DERBY-3790. The name of the junit test is store.KeepDisposableStatsPropertyTest. Had to make changes to this test to backport it to 10.8 but without the fix for DEBRY-3790 and with the absence of drop statistics procedure, the test really does not make much sense for 10.8 codeline. The test uses drop statistics procedure and it is mainly testing DERBY-3790 to make sure that the orphaned stats are being deleted or left behind based on whether the property is set to true or false. But since we do not have drop statistics procedure and we do not have DERBY-3790 fixed in 10.8, we can't really meaningfully run the KeepDisposableStatsPropertyTest in 10.8. In any case, I have changed the test so that atleast it will not fail in 10.8 but it is not able to truly test the property. May be we can test this property through upgrade suite where we will create orphaned stats because of DERBY-5681 on older releases and we will find that when the property is set to true, even after upgrade, we will have orphaned stats but when property is set to false, after upgrade, orphaned stats are deleted. Investigate if request for update statistics can be skipped for certain kind of indexes, one instance may be unique indexes based on one column. Key: DERBY-3790 URL: https://issues.apache.org/jira/browse/DERBY-3790 Project: Derby Issue Type: Improvement Components: Store Affects Versions: 10.5.1.1 Reporter: Mamta A. Satoor Assignee: Kristian Waagan Fix For: 10.9.1.0 Attachments: derby-3790-1a-skip_stats_scui.diff, derby-3790-1b-skip_stats_scui.diff, derby-3790-1c-skip_stats_scui.diff, derby-3790-2a-minor_test_improvements.diff DERBY-269 provided a manual way to update the statisitcs. There was some discussion in that jira entry for possibly optimizing the cases where there is no need to update the statistics. I will enter the related comments from that jira entry here for reference. ** Knut Anders Hatlen - 18/Jul/08 12:39 AM If I have understood correctly, unique indexes always have up to date cardinality statistics because cardinality == row count. If that's the case, one possible optimization is to skip the unique indexes when SYSCS_UPDATE_STATISTICS is called. ** ** Mike Matrigali - 18/Jul/08 09:48 AM is the cardinality of a unique index 1 or is it row count? It is also more complicated than just skipping unique indexes, it depends on the number of columns in the index because in a multi-column index, multiple cardinalities are calculated. So for instance on an index on columns A,B,C there are actually 3 cardinalities calculated: A A,B A,B,C I agree that the calculation of cardinality of A,B,C could/should be short circuited for a unique index. ** ** Knut Anders Hatlen - 18/Jul/08 03:25 PM Mike, It looks to me as if the cardinality is the number of unique values, so I think the cardinality of a unique index is equal to its row count (for the full key, that is).
[jira] [Commented] (DERBY-5680) indexStat daemon processing tables over and over even when there are no changes in the tables
[
https://issues.apache.org/jira/browse/DERBY-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13696399#comment-13696399
]
ASF subversion and git services commented on DERBY-5680:
Commit 1498173 from [~mamtas]
[ https://svn.apache.org/r1498173 ]
DERBY-5680(indexStat daemon processing tables over and over even when there are
no changes in the tables)
KeepDisposableStatsPropertyTest test is meant for DERBY-3790 which is not in in
10.8 codeline and hence should not be run in 10.8
indexStat daemon processing tables over and over even when there are no
changes in the tables
-
Key: DERBY-5680
URL: https://issues.apache.org/jira/browse/DERBY-5680
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.8.2.2, 10.9.1.0
Reporter: Brett Bergquist
Assignee: Kristian Waagan
Fix For: 10.8.3.1, 10.9.1.0
Attachments: derby-5680-1a-drop_orphaned_stats.diff,
derby-5680-1b-remove_disposable_stats.diff,
derby-5680-2a-remove_redundant_check.diff,
derby-5680-3a-rename_debug_property.diff,
DERBY5680_backportTo108_patch1_diff.txt,
DERBY5680_backportTo108_patch1_stat.txt
I think there is something wrong with the indexStats.
The problem happens on many tables in the database.
None of these tables are changing however, no inserts or deletes or updates.
They are being queried, however.
Here is one such table.
Here is the statistics for this table:
Table (Index) 2 3
ACCOUNTTABLE_CONFIG_BUNDLE (SQL081029110443810) numunique= 38390
numrows= 38390 2012-03-30 13:00:26.84
ACCOUNTTABLE_CONFIG_BUNDLE (SQL100922215819290) numunique= 38390
numrows= 38390 2012-03-30 13:00:26.917
There are in fact 38390 rows in the table.
Here is some of the indexStat trace:
Fri Mar 30 12:47:12 EDT 2012 Thread[DRDAConnThread_43,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: update scheduled,
reason=[t-est=38390, i-est=2355 = cmp=2.7912562815443245] (queueSize=12)
Fri Mar 30 12:47:48 EDT 2012 Thread[index-stat-thread,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: wrote stats for index
SQL081029110443810 (fc33890d-011d-491f-3d8c-376d74d3): rows=38390,
card=[38390]
Fri Mar 30 12:47:48 EDT 2012 Thread[index-stat-thread,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: wrote stats for index
SQL100922215819290 (75608675-012b-3c38-b55c-43ea6398): rows=38390,
card=[38390]
Fri Mar 30 12:47:48 EDT 2012 Thread[index-stat-thread,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: scan durations
(c30625=91ms,c30625=98ms)
Fri Mar 30 12:47:48 EDT 2012 Thread[index-stat-thread,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: generation complete (210 ms)
Fri Mar 30 12:47:49 EDT 2012 Thread[DRDAConnThread_44,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: update scheduled,
reason=[t-est=38390, i-est=2355 = cmp=2.7912562815443245] (queueSize=19)
Fri Mar 30 12:48:25 EDT 2012 Thread[index-stat-thread,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: wrote stats for index
SQL081029110443810 (fc33890d-011d-491f-3d8c-376d74d3): rows=38390,
card=[38390]
Fri Mar 30 12:48:25 EDT 2012 Thread[index-stat-thread,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: wrote stats for index
SQL100922215819290 (75608675-012b-3c38-b55c-43ea6398): rows=38390,
card=[38390]
Fri Mar 30 12:48:25 EDT 2012 Thread[index-stat-thread,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: scan durations
(c30625=93ms,c30625=95ms)
Fri Mar 30 12:48:25 EDT 2012 Thread[index-stat-thread,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: generation complete (211 ms)
Fri Mar 30 12:48:25 EDT 2012 Thread[DRDAConnThread_50,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: update scheduled,
reason=[t-est=38390, i-est=2355 = cmp=2.7912562815443245] (queueSize=18)
Fri Mar 30 12:48:57 EDT 2012 Thread[index-stat-thread,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: wrote stats for index
SQL081029110443810 (fc33890d-011d-491f-3d8c-376d74d3): rows=38390,
card=[38390]
Fri Mar 30 12:48:57 EDT 2012 Thread[index-stat-thread,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: wrote stats for index
SQL100922215819290 (75608675-012b-3c38-b55c-43ea6398): rows=38390,
card=[38390]
Fri Mar 30 12:48:57 EDT 2012 Thread[index-stat-thread,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: generation complete (243 ms)
Fri Mar 30 12:49:27 EDT 2012 Thread[DRDAConnThread_56,5,main] {istat}
PKG_9145E_V1.ACCOUNTTABLE_CONFIG_BUNDLE: update scheduled,
reason=[t-est=38390, i-est=2355 = cmp=2.7912562815443245]
[jira] [Commented] (DERBY-3790) Investigate if request for update statistics can be skipped for certain kind of indexes, one instance may be unique indexes based on one column.
[ https://issues.apache.org/jira/browse/DERBY-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13696400#comment-13696400 ] ASF subversion and git services commented on DERBY-3790: Commit 1498173 from [~mamtas] [ https://svn.apache.org/r1498173 ] DERBY-5680(indexStat daemon processing tables over and over even when there are no changes in the tables) KeepDisposableStatsPropertyTest test is meant for DERBY-3790 which is not in in 10.8 codeline and hence should not be run in 10.8 Investigate if request for update statistics can be skipped for certain kind of indexes, one instance may be unique indexes based on one column. Key: DERBY-3790 URL: https://issues.apache.org/jira/browse/DERBY-3790 Project: Derby Issue Type: Improvement Components: Store Affects Versions: 10.5.1.1 Reporter: Mamta A. Satoor Assignee: Kristian Waagan Fix For: 10.9.1.0 Attachments: derby-3790-1a-skip_stats_scui.diff, derby-3790-1b-skip_stats_scui.diff, derby-3790-1c-skip_stats_scui.diff, derby-3790-2a-minor_test_improvements.diff DERBY-269 provided a manual way to update the statisitcs. There was some discussion in that jira entry for possibly optimizing the cases where there is no need to update the statistics. I will enter the related comments from that jira entry here for reference. ** Knut Anders Hatlen - 18/Jul/08 12:39 AM If I have understood correctly, unique indexes always have up to date cardinality statistics because cardinality == row count. If that's the case, one possible optimization is to skip the unique indexes when SYSCS_UPDATE_STATISTICS is called. ** ** Mike Matrigali - 18/Jul/08 09:48 AM is the cardinality of a unique index 1 or is it row count? It is also more complicated than just skipping unique indexes, it depends on the number of columns in the index because in a multi-column index, multiple cardinalities are calculated. So for instance on an index on columns A,B,C there are actually 3 cardinalities calculated: A A,B A,B,C I agree that the calculation of cardinality of A,B,C could/should be short circuited for a unique index. ** ** Knut Anders Hatlen - 18/Jul/08 03:25 PM Mike, It looks to me as if the cardinality is the number of unique values, so I think the cardinality of a unique index is equal to its row count (for the full key, that is). You're right that we can't short circuit it if we have a multi-column index. I don't know if it's worth the extra complexity to short circuit the A,B,C case, since we'd have to scan the entire index anyway. For a single-column unique index it sounds like a good idea, though. ** -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6267) Add ability to compactly specify a complete query plan in an optimizer override.
[ https://issues.apache.org/jira/browse/DERBY-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697965#comment-13697965 ] ASF subversion and git services commented on DERBY-6267: Commit 1499012 from [~rhillegas] [ https://svn.apache.org/r1499012 ] DERBY-6267: Add first rev of complete plan overrides; merged derby-6267-01-ae-compactSyntax.diff to head of trunk. Add ability to compactly specify a complete query plan in an optimizer override. Key: DERBY-6267 URL: https://issues.apache.org/jira/browse/DERBY-6267 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.11.0.0 Reporter: Rick Hillegas Labels: derby_triage10_11 Attachments: derby-6267-01-ac-compactSyntax.diff, derby-6267-01-ad-compactSyntax.diff, derby-6267-01-ae-compactSyntax.diff It would be nice to be able to override the optimizer's choice and specify a complete query plan using the compact summary syntax output by XMLOptTrace. Given how the optimizer handles a statement, this would require binding a query plan at the query block level. Two obvious candidates for such a feature are: 1) Extend the use of DERBY-PROPERTIES in the comments of a query. 2) Add an extra clause to query blocks. The clause would have to be a clearly marked Derby extension. (1) might look like this (here we add a new fullQueryPlan property): select tablename from sys.systables t, sys.syscolumns c, sys.sysaliases a where t.tablename = c.columnname and c.columnname = a.alias -- DERBY-PROPERTIES fullQueryPlan = (SYSCOLUMNS_HEAP # SYSALIASES_INDEX1) # SYSTABLES_INDEX1 union all select tablename from sys.systables t, sys.syscolumns c, sys.sysaliases a, sys.syssequences s where t.tablename = c.columnname and c.columnname = a.alias and a.alias = s.sequencename -- DERBY-PROPERTIES fullQueryPlan = ((SYSCOLUMNS_HEAP # SYSTABLES_INDEX1) # SYSALIASES_INDEX1) # SYSSEQUENCES_INDEX2 ; (2) might look like this (here we add a new using derby join order clause): select tablename from sys.systables t, sys.syscolumns c, sys.sysaliases a where t.tablename = c.columnname and c.columnname = a.alias using derby join order (SYSCOLUMNS_HEAP # SYSALIASES_INDEX1) # SYSTABLES_INDEX1 union all select tablename from sys.systables t, sys.syscolumns c, sys.sysaliases a, sys.syssequences s where t.tablename = c.columnname and c.columnname = a.alias and a.alias = s.sequencename using derby join order ((SYSCOLUMNS_HEAP # SYSTABLES_INDEX1) # SYSALIASES_INDEX1) # SYSSEQUENCES_INDEX2 ; Here's a comparison of these approaches: (1) + Portability: the same query text can be used against different RDBMSes. - Parsing of DERBY-PROPERTIES happens outside the grammer. (2) + Parsing happens in the parser. - Not portable. I slightly prefer approach (1). If I pursue that approach, I would like to see if I can move the parsing into the parser. I am interested in other opinions about how to address this feature. Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5979) ant release target creates a release.properties that has conflicting line endings so automatic checkin fails
[
https://issues.apache.org/jira/browse/DERBY-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13698728#comment-13698728
]
ASF subversion and git services commented on DERBY-5979:
Commit 1499244 from [~dyret]
[ https://svn.apache.org/r1499244 ]
DERBY-5979: Part b: 1) Make properties.dir absolute by prepending ${basedir}.
This way the release-targets work even when cwd is not equal to ${basedir} (as
could be the case when invoking those target from within an IDE). 2) Change the
value of derby.junit.jvm from java to ${java.home}/bin/java. This ensures that
junit-ant-tasks work even if invoked from an environment (such as an IDE) where
the JAVA_HOME jvm may be different from the first jvm in PATH.
ant release target creates a release.properties that has conflicting line
endings so automatic checkin fails
Key: DERBY-5979
URL: https://issues.apache.org/jira/browse/DERBY-5979
Project: Derby
Issue Type: Bug
Components: Build tools
Reporter: Kathey Marsden
Assignee: Dyre Tjeldvoll
Labels: derby_triage10_11
Attachments: derby-5979-1.diff, derby-5979-2.diff,
derby-5979-3-a.diff, derby-5979-3-b.diff
The ant release target on Windows creates release.properties with
inconsistent line endings that prevent checkin.
This may be a configuration issue. I have *.properties =
svn:eol-style=native which I think is correct but I could not diff or checkin
the file until I removed the dos line endings. There are similar issues with
the release notes but because they are not checked in as part of the a script
we document how to fix them up.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6114) OOME in XAMemTest.testDerby4137_TransactionTimeoutSpecifiedNotExceeded
[ https://issues.apache.org/jira/browse/DERBY-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13698746#comment-13698746 ] ASF subversion and git services commented on DERBY-6114: Commit 1499256 from [~knutanders] [ https://svn.apache.org/r1499256 ] DERBY-6114: Fold Java5SingletonTimerFactory into SingletonTimerFactory OOME in XAMemTest.testDerby4137_TransactionTimeoutSpecifiedNotExceeded -- Key: DERBY-6114 URL: https://issues.apache.org/jira/browse/DERBY-6114 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.2.2, 10.10.1.1 Environment: Derby head of 10.10 branch. ubuntu3 slave on builds.apache.org. Java SE 7u4, 64-bit. java.vendor=Oracle Corporation java.runtime.version=1.7.0_04-b20 os.name=Linux os.arch=amd64 os.version=3.2.0-38-generic Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.9.2.2, 10.10.1.3, 10.11.0.0 Attachments: backport-10.10.diff, derby-6114-1a-purge.diff, derby-6114-2a-collapse-on-trunk.diff, derby.log, error-stacktrace.out Seen twice in a row in https://builds.apache.org/job/Derby-10.10-suites.All/ : junit-lowmem: [junit] Running org.apache.derbyTesting.functionTests.tests.memory._Suite [junit] Exception in thread DRDAConnThread_11 java.lang.OutOfMemoryError: GC overhead limit exceeded [junit] at java.util.Properties$LineReader.init(Properties.java:405) [junit] at java.util.Properties.load(Properties.java:341) [junit] at java.util.PropertyResourceBundle.init(PropertyResourceBundle.java:130) [junit] at java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2610) [junit] at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1436) [junit] at java.util.ResourceBundle.findBundle(ResourceBundle.java:1400) [junit] at java.util.ResourceBundle.findBundle(ResourceBundle.java:1354) [junit] at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1296) [junit] at java.util.ResourceBundle.getBundle(ResourceBundle.java:796) [junit] at org.apache.derby.iapi.services.i18n.MessageService.getBundleWithEnDefault(MessageService.java:318) [junit] at org.apache.derby.iapi.services.i18n.MessageService.getBundleForLocale(MessageService.java:53) [junit] at org.apache.derby.iapi.services.i18n.MessageService.getBundle(MessageService.java:302) [junit] at org.apache.derby.iapi.services.i18n.MessageService.getCompleteMessage(MessageService.java:97) [junit] at org.apache.derby.iapi.error.SQLWarningFactory.newSQLWarning(SQLWarningFactory.java:97) [junit] at org.apache.derby.iapi.error.SQLWarningFactory.newSQLWarning(SQLWarningFactory.java:50) [junit] at org.apache.derby.iapi.jdbc.BrokeredConnection.statementHoldabilityCheck(BrokeredConnection.java:736) [junit] at org.apache.derby.iapi.jdbc.BrokeredConnection.prepareStatement(BrokeredConnection.java:690) [junit] at org.apache.derby.impl.drda.DRDAStatement.prepare(DRDAStatement.java:669) [junit] at org.apache.derby.impl.drda.DRDAStatement.explicitPrepare(DRDAStatement.java:630) [junit] at org.apache.derby.impl.drda.DRDAConnThread.parsePRPSQLSTT(DRDAConnThread.java:3912) [junit] at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:811) [junit] at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:295) [junit] Tests run: 67, Failures: 0, Errors: 1, Time elapsed: 1,571.059 sec [junit] Test org.apache.derbyTesting.functionTests.tests.memory._Suite FAILED -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6285) Use factory method to create thread pool for timed login
[
https://issues.apache.org/jira/browse/DERBY-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13698747#comment-13698747
]
ASF subversion and git services commented on DERBY-6285:
Commit 1499257 from [~knutanders]
[ https://svn.apache.org/r1499257 ]
DERBY-6285: Use factory method to create thread pool for timed login
Use factory method to create thread pool for timed login
Key: DERBY-6285
URL: https://issues.apache.org/jira/browse/DERBY-6285
Project: Derby
Issue Type: Improvement
Components: JDBC
Affects Versions: 10.10.1.1
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Priority: Trivial
Attachments: derby-6285-1a.diff
InternalDriver creates a thread pool for running timed logins like this:
private static final ThreadPoolExecutor _executorPool =
new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60L,
TimeUnit.SECONDS,
new SynchronousQueueRunnable());
static {
_executorPool.setThreadFactory(new DaemonThreadFactory());
}
The java.util.concurrent.Executors class has factory methods that create
thread pools and hide the details such as choosing keep-alive time and which
kind of queue to use.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5979) ant release target creates a release.properties that has conflicting line endings so automatic checkin fails
[ https://issues.apache.org/jira/browse/DERBY-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13698777#comment-13698777 ] ASF subversion and git services commented on DERBY-5979: Commit 1499287 from [~dyret] [ https://svn.apache.org/r1499287 ] DERBY-5979: Part a: Do not use \n to terminate lines in Apache License header String constant and instead join the line strings with the value of line.separator property. ant release target creates a release.properties that has conflicting line endings so automatic checkin fails Key: DERBY-5979 URL: https://issues.apache.org/jira/browse/DERBY-5979 Project: Derby Issue Type: Bug Components: Build tools Reporter: Kathey Marsden Assignee: Dyre Tjeldvoll Labels: derby_triage10_11 Attachments: derby-5979-1.diff, derby-5979-2.diff, derby-5979-3-a.diff, derby-5979-3-b.diff The ant release target on Windows creates release.properties with inconsistent line endings that prevent checkin. This may be a configuration issue. I have *.properties = svn:eol-style=native which I think is correct but I could not diff or checkin the file until I removed the dos line endings. There are similar issues with the release notes but because they are not checked in as part of the a script we document how to fix them up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6287) Don't use reflection to call Java 6 methods in FileUtil
[ https://issues.apache.org/jira/browse/DERBY-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13698808#comment-13698808 ] ASF subversion and git services commented on DERBY-6287: Commit 1499317 from [~knutanders] [ https://svn.apache.org/r1499317 ] DERBY-6287: Don't use reflection to call Java 6 methods in FileUtil Don't use reflection to call Java 6 methods in FileUtil --- Key: DERBY-6287 URL: https://issues.apache.org/jira/browse/DERBY-6287 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.11.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: derby-6287-1a.diff The FileUtil class uses reflection to call the following java.io.File methods: setWritable(boolean, boolean) setReadable(boolean, boolean) setExecutable(boolean, boolean) Reflection was used because the methods were introduced in Java 6, and the code had to run on older platforms. Now Java 6 is the lowest supported platform, so we can call the methods directly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6256) Move the XmlVTI into the product.
[ https://issues.apache.org/jira/browse/DERBY-6256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13699197#comment-13699197 ] ASF subversion and git services commented on DERBY-6256: Commit 1499484 from [~rhillegas] [ https://svn.apache.org/r1499484 ] DERBY-6256: Make XmlVTI take a file name argument rather than a file URL argument; commit derby-6256-03-aa-useFileNotURL.diff. Move the XmlVTI into the product. - Key: DERBY-6256 URL: https://issues.apache.org/jira/browse/DERBY-6256 Project: Derby Issue Type: Improvement Components: SQL, Tools Affects Versions: 10.11.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Labels: derby_triage10_11 Attachments: derby-6256-01-aa-move-XmlVTI-into-product.diff, derby-6256-02-aa-allowParentTags.diff, derby-6256-03-aa-useFileNotURL.diff The XmlVTI under derbyDemo has been useful to me for many years. It has become even more useful now that Derby supports varargs. That is because varargs make it very easy to declare an XmlVTI. At this point, I think it is worth re-phrasing the XmlVTI in terms of varargs and moving it into the product so that we can use it for internal table functions. There is no rush to expose XmlVTI as part of Derby's public api, but we could consider doing that if other people find this table function to be useful. The XmlVTI is a table function which turns an xml file into a tabular data set which you can query via sql. When you declare an XmlVTI, you state the following arguments: 1) The url of an xml file. 2) The name of the element in the xml file which you want to treat as a record or row. 3) The names of the attributes and subelements of that record which you want to treat as columns. Now that we have varargs, it is possible to represent this trailing argument as a variable length argument list. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
