[jira] Updated: (DERBY-973) Restore fails in OnlineBackupTest1
[ https://issues.apache.org/jira/browse/DERBY-973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ole Solberg updated DERBY-973: -- Issue Type: Bug (was: Test) > Restore fails in OnlineBackupTest1 > -- > > Key: DERBY-973 > URL: https://issues.apache.org/jira/browse/DERBY-973 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.2.1.6 > Environment: Solaris 10 3/05 s10_74L2a X86 - SunOS 5.10 Generic, JVM: > Sun Microsystems Inc. 1.5.0_04 >Reporter: Ole Solberg > Attachments: 377370.zip, derby.log > > > "Signature": > * Diff file storeall/storemore/OnlineBackupTest1.diff > *** Start: OnlineBackupTest1 jdk1.5.0_04 storeall:storemore 2006-02-13 > 16:17:08 *** > 6 del > < Restored From the Backup > 7 del > < Consistency Check is Done > 8 del > < database shutdown properly > 9 del > < End Online Backup Test1 > 9 add > > ERROR XJ040: Failed to start database 'wombat', see the next exception for > > details. > > ERROR XSDG0: Page Page(1,Container(0, 14929)) could not be read from disk. > > SQL Exception: Failed to start database 'wombat', see the next exception > > for details. > Test Failed. > *** End: OnlineBackupTest1 jdk1.5.0_04 storeall:storemore 2006-02-13 > 16:18:08 *** -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3192) Cache session data in the client driver
[ https://issues.apache.org/jira/browse/DERBY-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll updated DERBY-3192: -- Derby Info: (was: [Patch Available]) Committed revision 597352. > Cache session data in the client driver > --- > > Key: DERBY-3192 > URL: https://issues.apache.org/jira/browse/DERBY-3192 > Project: Derby > Issue Type: Improvement > Components: JDBC, Network Client, Network Server, Performance, SQL >Affects Versions: 10.3.1.4 >Reporter: Dyre Tjeldvoll >Assignee: Dyre Tjeldvoll > Attachments: derby-3192-test.v1.diff, derby-3192-test.v1.stat > > > The reason for doing this is to avoid a rather > substantial performance hit observed when the client driver is used > together with an appserver that uses connection pooling. There are two > problems: > 1) The connection pool will compare the isolation level it has > stored for the connection with the value returned from > Connection.getTransactionIsolation() each and every time someone > requests a new connection from the pool. > 2) The users of the connection pool (ab)use it to avoid having to keep > track of their current connection. So each time a query needs to be > executed a call to the connection pool's getConnection() method is > made. Getting a connection from the connection pool like this also > means that a new PreparedStatement must be prepared each time. > The net result is that each query results in the following sequence: > getConnection() > getTransactionIsolation() --> roundtrip + lookup in server's statement cache > prepareStatment() --> roundtrip + lookup in server's statement cache > executeQuery()--> roundtrip > Arguably this is a "user error" but when suggesting this I'm kindly > informed that this works "just fine" with other datbases (such as > PostgreSQL and ORACLE). > The reason why it works is that these databases do statement caching > in the driver. I've tried to implement a very (too) simple statement > cache in Derby's client driver and to re-enable caching of the > isolation level (see > https://issues.apache.org/jira/browse/DERBY-1148). With these changes > I observe a marked performance improvement when running with appserver > load. > A proper statment cache cannot be implemented without knowing what the > current schema is. If the current schema has changed since the > statement was prepared, it is no longer valid and must be evicted from > the cache. > The problem with caching both the isolation level and the current schema in > the driver is that both can change on the server without the client > detecting it (through SQL and XA and possibly stored procedures). > I think this problem can be overcome if we piggy-back the information we > would > like to cache on messages going back to the client. This can be done by > utilizing the EXCSQLSET DRDA command. According to the DRDA spec (v4, volume > 3, > page 359-360) it is possible to add one or more SQLSTT objects after SQLCARD > in the reply, > I think it would be possible to cache additional session information when > this becomes relevant. It > would also be possible to use EXCSQLSET to batch session state changes > going from the client to the server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3142) sysinfo ignores derby.ui.locale
[ https://issues.apache.org/jira/browse/DERBY-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-3142: -- Derby Info: [Patch Available] > sysinfo ignores derby.ui.locale > --- > > Key: DERBY-3142 > URL: https://issues.apache.org/jira/browse/DERBY-3142 > Project: Derby > Issue Type: Bug > Components: Localization, Tools >Affects Versions: 10.2.2.0, 10.3.1.4, 10.4.0.0 >Reporter: Knut Anders Hatlen >Assignee: Knut Anders Hatlen >Priority: Minor > Attachments: d3142-1.diff, d3142-2.diff, d3142-2a.diff, > d3142-with-test.diff, d3142-with-test.stat > > > Sysinfo messages are localized using the system's default locale instead of > the locale specified by derby.ui.locale. > Example: > $ java -Dderby.ui.locale=de_DE -jar derbyrun.jar sysinfo|head > > -- Java Information -- > Java Version:1.6.0_01 > Java Vendor: Sun Microsystems Inc. > Java home: /usr/jdk/instances/jdk1.6.0/jre > Java classpath: derbyrun.jar > OS name: SunOS > OS architecture: x86 > OS version: 5.11 > Java user name: kah > Java user home: /home/kah > Setting the default locale works correctly: > $ LC_ALL=de_DE.UTF-8 java -jar derbyrun.jar sysinfo|head > -- Java-Informationen -- > Java-Version: 1.6.0_01 > Java-Anbieter: Sun Microsystems Inc. > Java-Home: /usr/jdk/instances/jdk1.6.0/jre > Java-Klassenpfad: derbyrun.jar > Name des Betriebssystems: SunOS > Architektur des Betriebssystems: x86 > Betriebssystemversion: 5.11 > Java-Benutzername: kah > Java-Benutzerausgangsverzeichnis: /home/kah -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3142) sysinfo ignores derby.ui.locale
[ https://issues.apache.org/jira/browse/DERBY-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-3142: -- Attachment: d3142-with-test.stat d3142-with-test.diff I have now added a test to the patch. Derbyall and suites.All ran cleanly. The test loads the sysinfo class in a separate class loader a number of times with different combinations of default locale and derby.ui.locale. A separate class loader was needed because the tools detect which locale they are running under the first time they are loaded, and they will not detect changes to the locale setting unless the classes are unloaded and then reloaded. Also, the test does not run under a security manager. The reason for this is that the test requires permission to create a class loader. I see in other tests (such as AggregateClassLoadingTest) that we don't want to grant that permission to derbyTesting.jar since then no tests fail if code in derby.jar forgets to use privileged blocks when creating class loaders. > sysinfo ignores derby.ui.locale > --- > > Key: DERBY-3142 > URL: https://issues.apache.org/jira/browse/DERBY-3142 > Project: Derby > Issue Type: Bug > Components: Localization, Tools >Affects Versions: 10.2.2.0, 10.3.1.4, 10.4.0.0 >Reporter: Knut Anders Hatlen >Assignee: Knut Anders Hatlen >Priority: Minor > Attachments: d3142-1.diff, d3142-2.diff, d3142-2a.diff, > d3142-with-test.diff, d3142-with-test.stat > > > Sysinfo messages are localized using the system's default locale instead of > the locale specified by derby.ui.locale. > Example: > $ java -Dderby.ui.locale=de_DE -jar derbyrun.jar sysinfo|head > > -- Java Information -- > Java Version:1.6.0_01 > Java Vendor: Sun Microsystems Inc. > Java home: /usr/jdk/instances/jdk1.6.0/jre > Java classpath: derbyrun.jar > OS name: SunOS > OS architecture: x86 > OS version: 5.11 > Java user name: kah > Java user home: /home/kah > Setting the default locale works correctly: > $ LC_ALL=de_DE.UTF-8 java -jar derbyrun.jar sysinfo|head > -- Java-Informationen -- > Java-Version: 1.6.0_01 > Java-Anbieter: Sun Microsystems Inc. > Java-Home: /usr/jdk/instances/jdk1.6.0/jre > Java-Klassenpfad: derbyrun.jar > Name des Betriebssystems: SunOS > Architektur des Betriebssystems: x86 > Betriebssystemversion: 5.11 > Java-Benutzername: kah > Java-Benutzerausgangsverzeichnis: /home/kah -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3217) ErrorStreamTest failing on ibm j9 jvm
[ https://issues.apache.org/jira/browse/DERBY-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544745 ] Vemund Østgaard commented on DERBY-3217: I don't know. All I see is that DataSourceConnector does tihis: > ErrorStreamTest failing on ibm j9 jvm > - > > Key: DERBY-3217 > URL: https://issues.apache.org/jira/browse/DERBY-3217 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.4.0.0 > Environment: J9 - VM for the Java(TM) platform, Version 2.3 > (c) Copyright IBM Corp. 1991, 2006 All Rights Reserved > Target: 20061023_08962_lHdSMR (Windows XP 5.1 build 2600 Service Pack 2 x86) > JIT - 20060629_1804ifx1_r8 >Reporter: Mike Matrigali >Assignee: Vemund Østgaard > > Getting the following junit tests failures on just on the j9 jvm platform > running on windows: > There were 11 failures: > 1) > testDefault(org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest)junit.framework.AssertionFailedError: > shutdown engine not implemened > at > org.apache.derbyTesting.junit.DataSourceConnector.shutEngine(DataSourceConnector.java:130) > at > org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1091) > at > org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest.testDefault(ErrorStreamTest.java:128) > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) > at .(Unknown Source) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95) > 2) > testFile(org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest)junit.framework.AssertionFailedError: > shutdown engine not implemened > at > org.apache.derbyTesting.junit.DataSourceConnector.shutEngine(DataSourceConnector.java:130) > at > org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1091) > at > org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest.testFile(ErrorStreamTest.java:141) > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) > at .(Unknown Source) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95) > 3) > testWrongFile(org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest)junit.framework.AssertionFailedError: > shutdown engine not implemened > at > org.apache.derbyTesting.junit.DataSourceConnector.shutEngine(DataSourceConnector.java:130) > at > org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1091) > at > org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest.testWrongFile(ErrorStreamTest.java:160) > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) > at .(Unknown Source) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95) > 4) > testMethod(org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest)junit.framework.AssertionFailedError: > shutdown engine not implemened > at > org.apache.derbyTesting.junit.DataSourceConnector.shutEngine(DataSourceConnector.java:130) > at > org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1091) > at > org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest.testMethod(ErrorStreamTest.java:179) > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) > at .(Unknown Source) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95) > 5) > testWrongMethod(org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest)junit.framework.AssertionFailedError: > shutdown engine not implemened > at > org.apache.derbyTesting.junit.DataSourceConnector.shutEngine(DataSourceConnector.java:130) > at > org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1091) > at > org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest.testWrongMethod(ErrorStreamTest.java:198) > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) > at .(Unknown Source) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95) > 6) > testField(org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest)junit.framework.AssertionFailedError: > shutdown engine not implemened > at > org.apache.derbyTesting.junit.DataSourceConnector.shutEngine(DataSourceConnector.java:130) > at > org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1091) > at > org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest.testField(ErrorStreamTest.java:217) > at java.l
[jira] Issue Comment Edited: (DERBY-3217) ErrorStreamTest failing on ibm j9 jvm
[
https://issues.apache.org/jira/browse/DERBY-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544745
]
vemund edited comment on DERBY-3217 at 11/22/07 1:44 AM:
--
I don't know. All I see is that DataSourceConnector does this:
public void shutEngine() throws SQLException {
Assert.fail("shutdown engine not implemened");
}
While DriverManagerConnector does:
public void shutEngine() throws SQLException {
getConnectionByAttributes("jdbc:derby:", "shutdown", "true");
}
I figured it was because DataSource did not support shutting down the engine.
was (Author: vemund):
I don't know. All I see is that DataSourceConnector does tihis:
> ErrorStreamTest failing on ibm j9 jvm
> -
>
> Key: DERBY-3217
> URL: https://issues.apache.org/jira/browse/DERBY-3217
> Project: Derby
> Issue Type: Bug
> Components: Regression Test Failure
>Affects Versions: 10.4.0.0
> Environment: J9 - VM for the Java(TM) platform, Version 2.3
> (c) Copyright IBM Corp. 1991, 2006 All Rights Reserved
> Target: 20061023_08962_lHdSMR (Windows XP 5.1 build 2600 Service Pack 2 x86)
> JIT - 20060629_1804ifx1_r8
>Reporter: Mike Matrigali
>Assignee: Vemund Østgaard
>
> Getting the following junit tests failures on just on the j9 jvm platform
> running on windows:
> There were 11 failures:
> 1)
> testDefault(org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest)junit.framework.AssertionFailedError:
> shutdown engine not implemened
> at
> org.apache.derbyTesting.junit.DataSourceConnector.shutEngine(DataSourceConnector.java:130)
> at
> org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1091)
> at
> org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest.testDefault(ErrorStreamTest.java:128)
> at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
> at .(Unknown Source)
> at
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95)
> 2)
> testFile(org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest)junit.framework.AssertionFailedError:
> shutdown engine not implemened
> at
> org.apache.derbyTesting.junit.DataSourceConnector.shutEngine(DataSourceConnector.java:130)
> at
> org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1091)
> at
> org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest.testFile(ErrorStreamTest.java:141)
> at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
> at .(Unknown Source)
> at
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95)
> 3)
> testWrongFile(org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest)junit.framework.AssertionFailedError:
> shutdown engine not implemened
> at
> org.apache.derbyTesting.junit.DataSourceConnector.shutEngine(DataSourceConnector.java:130)
> at
> org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1091)
> at
> org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest.testWrongFile(ErrorStreamTest.java:160)
> at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
> at .(Unknown Source)
> at
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95)
> 4)
> testMethod(org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest)junit.framework.AssertionFailedError:
> shutdown engine not implemened
> at
> org.apache.derbyTesting.junit.DataSourceConnector.shutEngine(DataSourceConnector.java:130)
> at
> org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1091)
> at
> org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest.testMethod(ErrorStreamTest.java:179)
> at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
> at .(Unknown Source)
> at
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95)
> 5)
> testWrongMethod(org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest)junit.framework.AssertionFailedError:
> shutdown engine not implemened
> at
> org.apache.derbyTesting.junit.DataSourceConnector.shutEngine(DataSourceConnector.java:130)
> at
> org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1091)
> at
> org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest.testWrongMethod(ErrorStreamTest.java:198)
> at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
> at .(Unknown Source)
> at
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTes
[jira] Commented: (DERBY-3156) Convert testing of derby error stream to JUnit
[ https://issues.apache.org/jira/browse/DERBY-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544746 ] Knut Anders Hatlen commented on DERBY-3156: --- Removed errorStream.out and logStream.out and committed revision 597356. > Convert testing of derby error stream to JUnit > -- > > Key: DERBY-3156 > URL: https://issues.apache.org/jira/browse/DERBY-3156 > Project: Derby > Issue Type: Test > Components: Test >Reporter: Vemund Østgaard >Assignee: Vemund Østgaard >Priority: Minor > Fix For: 10.4.0.0 > > Attachments: 3156-diff, 3156-diff.stat, 3156-diffv2, > 3156-diffv2.stat, 3156-diffv3, 3156-diffv3.stat, 3156-diffv4, > 3156-diffv4.stat, 3156-remove-old-tests-diff, 3156-remove-old-tests-diff.stat > > > Convert the tests that are related to derby error stream properties and > functionality. > Seems to be these two tests: > lang/logStream.java > lang/errorStream.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3220) (ReferencingClause) in CREATE TRIGGER statement not SQL compliant
[
https://issues.apache.org/jira/browse/DERBY-3220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernt M. Johnsen updated DERBY-3220:
Attachment: DERBY-3220-2.diff
DERBY-3220-doc-2.diff
Patch 2: Changed NEW_TABLE to NEW TABLE and OLD_TABLE to OLD TABLE in
TriggerTest, kept the old syntax in db2Compatibility. Also updated
BlobClob4BlobTest to SQL compliant trigger syntax. Improved doc patch.
> (ReferencingClause) in CREATE TRIGGER
> statement not SQL compliant
> -
>
> Key: DERBY-3220
> URL: https://issues.apache.org/jira/browse/DERBY-3220
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Reporter: Bernt M. Johnsen
>Assignee: Bernt M. Johnsen
>Priority: Minor
> Attachments: DERBY-3220-2.diff, DERBY-3220-doc-2.diff,
> DERBY-3220-doc.diff, DERBY-3220.diff
>
>
> Derby implements the following syntax:
> REFERENCING
> {
> { OLD | NEW } [ AS ] correlation-Name [ { OLD | NEW } [ AS ] correlation-Name
> ] |
> { OLD_TABLE | NEW_TABLE } [ AS ] Identifier [ { OLD_TABLE | NEW_TABLE }
> [AS] Identifier ]
> }
> The SQL standard specifies:
> ::=
> CREATE TRIGGER
> ON [ REFERENCING ]
>
> ...
> ::=
> OLD [ ROW ] [ AS ]
> | NEW [ ROW ] [ AS ]
> | OLD TABLE [ AS ]
> | NEW TABLE [ AS ]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3222) 'CollationTest' fails with ' expected:<1> but was:<0>' in testPolishCollation(CollationTest.java:402)
'CollationTest' fails with ' expected:<1> but was:<0>' in testPolishCollation(CollationTest.java:402) - Key: DERBY-3222 URL: https://issues.apache.org/jira/browse/DERBY-3222 Project: Derby Issue Type: Bug Components: Regression Test Failure Environment: OS: Solaris 10 8/07 s10x_u4wos_12b X86 64bits - SunOS 5.10 Generic_120012-14 JVM: Sun Microsystems Inc. 1.6.0_01-b06 Reporter: Ole Solberg Fix For: 10.3.1.5 See http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.6/testing/Limited/testSummary-597152.html : sol. There was 1 failure: 1) testPolishCollation(org.apache.derbyTesting.functionTests.tests.lang.CollationTest)junit.framework.AssertionFailedError: expected:<1> but was:<0> at org.apache.derbyTesting.functionTests.tests.lang.CollationTest.commonTestingForTerritoryBasedDB(CollationTest.java:1141) at org.apache.derbyTesting.functionTests.tests.lang.CollationTest.testPolishCollation(CollationTest.java:402) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3222) 'CollationTest' fails with ' expected:<1> but was:<0>' in testPolishCollation(CollationTest.java:402)
[ https://issues.apache.org/jira/browse/DERBY-3222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ole Solberg updated DERBY-3222: --- Affects Version/s: 10.3.1.5 Fix Version/s: (was: 10.3.1.5) > 'CollationTest' fails with ' expected:<1> but was:<0>' in > testPolishCollation(CollationTest.java:402) > - > > Key: DERBY-3222 > URL: https://issues.apache.org/jira/browse/DERBY-3222 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.3.1.5 > Environment: OS: Solaris 10 8/07 s10x_u4wos_12b X86 64bits - SunOS > 5.10 Generic_120012-14 > JVM: Sun Microsystems Inc. 1.6.0_01-b06 >Reporter: Ole Solberg > > See > http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.6/testing/Limited/testSummary-597152.html > : sol. > There was 1 failure: > 1) > testPolishCollation(org.apache.derbyTesting.functionTests.tests.lang.CollationTest)junit.framework.AssertionFailedError: > expected:<1> but was:<0> > at > org.apache.derbyTesting.functionTests.tests.lang.CollationTest.commonTestingForTerritoryBasedDB(CollationTest.java:1141) > at > org.apache.derbyTesting.functionTests.tests.lang.CollationTest.testPolishCollation(CollationTest.java:402) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.extensions.TestSetup.run(TestSetup.java:25) > at > org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.extensions.TestSetup.run(TestSetup.java:25) > at > org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.extensions.TestSetup.run(TestSetup.java:25) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3217) ErrorStreamTest failing on ibm j9 jvm
[
https://issues.apache.org/jira/browse/DERBY-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544779
]
John H. Embretsen commented on DERBY-3217:
--
As far as I can see, there is no documented way to shut down the Derby engine
when you are using a DataSource (I've only looked at EmbeddedSimpleDataSource
(used for Java ME) and EmbeddedDataSource).
However, I found that it is actually possible, by first setting the
databaseName to the empty String, then setting the connection attribute
"shutdown=true", and finally trying to obtain a connection. The exception is
the same as I get when shutting down the engine using DriverManager.
// Create an EmbeddedSimpleDataSource, setDatabaseName,
setCreateDatabase, getConnection...
try {
derbyDs.setDatabaseName("");
derbyDs.setConnectionAttributes("shutdown=true");
System.out.println("Shutting down engine...?");
derbyDs.getConnection();
} catch (SQLException ex) {
do {
System.err.println("- SQLException -");
System.err.println("SQLState: " + ex.getSQLState());
System.err.println("Error code: " + ex.getErrorCode());
//ex.printStackTrace();
ex = ex.getNextException();
} while (ex != null);
}
}
To restart the engine, create a new datasource object and set the correct
databaseName, then getConnection().
It seems that the engine is started on the first call to getConnection().
The test harness is a bit more complicated (less direct) in the way it sets
DataSource properties, but it should be possible to implement something like
this there as well, if needed.
> ErrorStreamTest failing on ibm j9 jvm
> -
>
> Key: DERBY-3217
> URL: https://issues.apache.org/jira/browse/DERBY-3217
> Project: Derby
> Issue Type: Bug
> Components: Regression Test Failure
>Affects Versions: 10.4.0.0
> Environment: J9 - VM for the Java(TM) platform, Version 2.3
> (c) Copyright IBM Corp. 1991, 2006 All Rights Reserved
> Target: 20061023_08962_lHdSMR (Windows XP 5.1 build 2600 Service Pack 2 x86)
> JIT - 20060629_1804ifx1_r8
>Reporter: Mike Matrigali
>Assignee: Vemund Østgaard
>
> Getting the following junit tests failures on just on the j9 jvm platform
> running on windows:
> There were 11 failures:
> 1)
> testDefault(org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest)junit.framework.AssertionFailedError:
> shutdown engine not implemened
> at
> org.apache.derbyTesting.junit.DataSourceConnector.shutEngine(DataSourceConnector.java:130)
> at
> org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1091)
> at
> org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest.testDefault(ErrorStreamTest.java:128)
> at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
> at .(Unknown Source)
> at
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95)
> 2)
> testFile(org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest)junit.framework.AssertionFailedError:
> shutdown engine not implemened
> at
> org.apache.derbyTesting.junit.DataSourceConnector.shutEngine(DataSourceConnector.java:130)
> at
> org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1091)
> at
> org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest.testFile(ErrorStreamTest.java:141)
> at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
> at .(Unknown Source)
> at
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95)
> 3)
> testWrongFile(org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest)junit.framework.AssertionFailedError:
> shutdown engine not implemened
> at
> org.apache.derbyTesting.junit.DataSourceConnector.shutEngine(DataSourceConnector.java:130)
> at
> org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1091)
> at
> org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest.testWrongFile(ErrorStreamTest.java:160)
> at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
> at .(Unknown Source)
> at
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95)
> 4)
> testMethod(org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest)junit.framework.AssertionFailedError:
> shutdown engine not implemened
> at
> org.apache.derbyTesting.junit.DataSourceConnector.shutEngine(DataSourceConnector.java:130)
> at
> org.apache.derbyTesting.junit.TestConfiguration.sh
[jira] Commented: (DERBY-3220) (ReferencingClause) in CREATE TRIGGER statement not SQL compliant
[
https://issues.apache.org/jira/browse/DERBY-3220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544789
]
Thomas Nielsen commented on DERBY-3220:
---
Smart move to change the existing tests for the NEW TABLE and OLD TABLE syntax,
but keeping the NEW_TABLE and OLD_TABLE in DB2 compliant mode :)
Small fix needed to DERBY-3220-2.diff:
- java/engine/org/apache/derby/impl/sql/compile/CreateTriggerNode.java but
touches one line, but no code change.
Doc path DERBY-3220-doc-2.diff looks good.
Running suitesAll now, but don't expect any problems due to this change.
> (ReferencingClause) in CREATE TRIGGER
> statement not SQL compliant
> -
>
> Key: DERBY-3220
> URL: https://issues.apache.org/jira/browse/DERBY-3220
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Reporter: Bernt M. Johnsen
>Assignee: Bernt M. Johnsen
>Priority: Minor
> Attachments: DERBY-3220-2.diff, DERBY-3220-doc-2.diff,
> DERBY-3220-doc.diff, DERBY-3220.diff
>
>
> Derby implements the following syntax:
> REFERENCING
> {
> { OLD | NEW } [ AS ] correlation-Name [ { OLD | NEW } [ AS ] correlation-Name
> ] |
> { OLD_TABLE | NEW_TABLE } [ AS ] Identifier [ { OLD_TABLE | NEW_TABLE }
> [AS] Identifier ]
> }
> The SQL standard specifies:
> ::=
> CREATE TRIGGER
> ON [ REFERENCING ]
>
> ...
> ::=
> OLD [ ROW ] [ AS ]
> | NEW [ ROW ] [ AS ]
> | OLD TABLE [ AS ]
> | NEW TABLE [ AS ]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2892) Closing a resultset after retrieving a large > 32665 bytes value with Network Server does not release locks
[ https://issues.apache.org/jira/browse/DERBY-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomohito Nakayama updated DERBY-2892: - Derby Info: [Existing Application Impact, Regression] (was: [Regression]) > Closing a resultset after retrieving a large > 32665 bytes value with Network > Server does not release locks > --- > > Key: DERBY-2892 > URL: https://issues.apache.org/jira/browse/DERBY-2892 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.2.2.0, 10.3.1.4 > Environment: JDK: build 1.6.0_01-b06 (WinXP & Gentoo/SuSE) > Hardware: Intel x86 > Client/Server environment >Reporter: Thomas Niessen >Assignee: Øystein Grøvlen >Priority: Critical > Fix For: 10.2.2.1 > > Attachments: DERBY-2892_07_10_07_try1_diff.txt, > DERBY-2892_07_10_07_try1_stat.txt, DERBY-2892_07_13_07_try2_diff.txt, > DERBY-2892_07_13_07_try2_stat.txt, derby-2892firstshot.diff, > protocolErrorRepro.zip > > > This is the same issue as DERBY-255 > (https://issues.apache.org/jira/browse/DERBY-255). The test attached to > DERBY-255 shows the locks being not released. Everything is fine when using > Derby 10.1.3.1 . > I would think it's a regression bug. > Output from sysinfo: > -- Java-Informationen -- > Java-Version: 1.6.0_01 > Java-Anbieter: Sun Microsystems Inc. > Java-Home: C:\work\applications\development\java\jdk1.6u1-SE\jre > Java-Klassenpfad: > C:\work\applications\development\derby-10.2.2.0/lib/derby.jar;C:\work\applications\development\derby- > 0.2.2.0/lib/derbynet.jar;C:\work\applications\development\derby-10.2.2.0/lib/derbyclient.jar;C:\work\applications\devel > pment\derby-10.2.2.0/lib/derbytools.jar > Name des Betriebssystems: Windows XP > Architektur des Betriebssystems: x86 > Betriebssystemversion: 5.1 > Java-Benutzername: thomas.niessen > Java-Benutzerausgangsverzeichnis: C:\Dokumente und > Einstellungen\thomas.niessen > Java-Benutzerverzeichnis: C:\work\applications\development\derby-10.2.2.0 > java.specification.name: Java Platform API Specification > java.specification.version: 1.6 > - Derby-Informationen > JRE - JDBC: Java SE 6 - JDBC 4.0 > [C:\work\applications\development\derby-10.2.2.0\lib\derby.jar] 10.2.2.0 - > (485682) > [C:\work\applications\development\derby-10.2.2.0\lib\derbytools.jar] 10.2.2.0 > - (485682) > [C:\work\applications\development\derby-10.2.2.0\lib\derbynet.jar] 10.2.2.0 - > (485682) > [C:\work\applications\development\derby-10.2.2.0\lib\derbyclient.jar] > 10.2.2.0 - (485682) > -- > - Informationen zur Lõndereinstellung - > Aktuelle Lõndereinstellung: [Deutsch/Deutschland [de_DE]] > Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [cs] > Version: 10.2.2.0 - (485682) > Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [de_DE] > Version: 10.2.2.0 - (485682) > Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [es] > Version: 10.2.2.0 - (485682) > Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [fr] > Version: 10.2.2.0 - (485682) > Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [hu] > Version: 10.2.2.0 - (485682) > Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [it] > Version: 10.2.2.0 - (485682) > Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [ja_JP] > Version: 10.2.2.0 - (485682) > Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [ko_KR] > Version: 10.2.2.0 - (485682) > Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [pl] > Version: 10.2.2.0 - (485682) > Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [pt_BR] > Version: 10.2.2.0 - (485682) > Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [ru] > Version: 10.2.2.0 - (485682) > Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [zh_CN] > Version: 10.2.2.0 - (485682) > Es wurde Unterst³tzung f³r die folgende Lõndereinstellung gefunden: [zh_TW] > Version: 10.2.2.0 - (485682) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3192) Cache session data in the client driver
[
https://issues.apache.org/jira/browse/DERBY-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544790
]
Knut Anders Hatlen commented on DERBY-3192:
---
Hi Dyre,
I think it's a very good idea to write the test up front, and the test looks
good. I'm not sure, but I think maybe the test needs to be excluded when
running JSR-169 tests since the stored procedures use DriverManager.
Some nits:
Some of the test cases have code which looks like this:
+Connection c = getConnection();
+Statement s = c.createStatement();
and
+Connection c = getConnection();
+PreparedStatement ps = c.prepareStatement("SELECT * FROM " + table,
It's probably better to use the helper methods create/prepareStatement() in
JDBCBaseTestCase, since they will automatically perform clean-up in tearDown().
It seems like the assertEquals() calls have swapped expected and actual value
(correct order is assertEquals(expected, actual)).
> Cache session data in the client driver
> ---
>
> Key: DERBY-3192
> URL: https://issues.apache.org/jira/browse/DERBY-3192
> Project: Derby
> Issue Type: Improvement
> Components: JDBC, Network Client, Network Server, Performance, SQL
>Affects Versions: 10.3.1.4
>Reporter: Dyre Tjeldvoll
>Assignee: Dyre Tjeldvoll
> Attachments: derby-3192-test.v1.diff, derby-3192-test.v1.stat
>
>
> The reason for doing this is to avoid a rather
> substantial performance hit observed when the client driver is used
> together with an appserver that uses connection pooling. There are two
> problems:
> 1) The connection pool will compare the isolation level it has
> stored for the connection with the value returned from
> Connection.getTransactionIsolation() each and every time someone
> requests a new connection from the pool.
> 2) The users of the connection pool (ab)use it to avoid having to keep
> track of their current connection. So each time a query needs to be
> executed a call to the connection pool's getConnection() method is
> made. Getting a connection from the connection pool like this also
> means that a new PreparedStatement must be prepared each time.
> The net result is that each query results in the following sequence:
> getConnection()
> getTransactionIsolation() --> roundtrip + lookup in server's statement cache
> prepareStatment() --> roundtrip + lookup in server's statement cache
> executeQuery()--> roundtrip
> Arguably this is a "user error" but when suggesting this I'm kindly
> informed that this works "just fine" with other datbases (such as
> PostgreSQL and ORACLE).
> The reason why it works is that these databases do statement caching
> in the driver. I've tried to implement a very (too) simple statement
> cache in Derby's client driver and to re-enable caching of the
> isolation level (see
> https://issues.apache.org/jira/browse/DERBY-1148). With these changes
> I observe a marked performance improvement when running with appserver
> load.
> A proper statment cache cannot be implemented without knowing what the
> current schema is. If the current schema has changed since the
> statement was prepared, it is no longer valid and must be evicted from
> the cache.
> The problem with caching both the isolation level and the current schema in
> the driver is that both can change on the server without the client
> detecting it (through SQL and XA and possibly stored procedures).
> I think this problem can be overcome if we piggy-back the information we
> would
> like to cache on messages going back to the client. This can be done by
> utilizing the EXCSQLSET DRDA command. According to the DRDA spec (v4, volume
> 3,
> page 359-360) it is possible to add one or more SQLSTT objects after SQLCARD
> in the reply,
> I think it would be possible to cache additional session information when
> this becomes relevant. It
> would also be possible to use EXCSQLSET to batch session state changes
> going from the client to the server.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DERBY-3220) (ReferencingClause) in CREATE TRIGGER statement not SQL compliant
[
https://issues.apache.org/jira/browse/DERBY-3220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544789
]
thomanie edited comment on DERBY-3220 at 11/22/07 4:23 AM:
-
Smart move to change the existing tests for the NEW TABLE and OLD TABLE syntax,
but keeping the NEW_TABLE and OLD_TABLE in DB2 compliant mode :)
Both DERBY-3220-2.diff and doc patch DERBY-3220-doc-2.diff looks good.
Running suitesAll now, but don't expect any problems due to this change.
was (Author: thomanie):
Smart move to change the existing tests for the NEW TABLE and OLD TABLE
syntax, but keeping the NEW_TABLE and OLD_TABLE in DB2 compliant mode :)
Small fix needed to DERBY-3220-2.diff:
- java/engine/org/apache/derby/impl/sql/compile/CreateTriggerNode.java but
touches one line, but no code change.
Doc path DERBY-3220-doc-2.diff looks good.
Running suitesAll now, but don't expect any problems due to this change.
> (ReferencingClause) in CREATE TRIGGER
> statement not SQL compliant
> -
>
> Key: DERBY-3220
> URL: https://issues.apache.org/jira/browse/DERBY-3220
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Reporter: Bernt M. Johnsen
>Assignee: Bernt M. Johnsen
>Priority: Minor
> Attachments: DERBY-3220-2.diff, DERBY-3220-doc-2.diff,
> DERBY-3220-doc.diff, DERBY-3220.diff
>
>
> Derby implements the following syntax:
> REFERENCING
> {
> { OLD | NEW } [ AS ] correlation-Name [ { OLD | NEW } [ AS ] correlation-Name
> ] |
> { OLD_TABLE | NEW_TABLE } [ AS ] Identifier [ { OLD_TABLE | NEW_TABLE }
> [AS] Identifier ]
> }
> The SQL standard specifies:
> ::=
> CREATE TRIGGER
> ON [ REFERENCING ]
>
> ...
> ::=
> OLD [ ROW ] [ AS ]
> | NEW [ ROW ] [ AS ]
> | OLD TABLE [ AS ]
> | NEW TABLE [ AS ]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3083) Network server demands a file called "derbynet.jar" in classpath
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544794 ] Aaron Digulla commented on DERBY-3083: -- >> storing these URLs in the system properties (or any global variable) is okay >> too, because this cannot be exploited from a remote attacker >That's an assumption that's hard to prove This is very easy to prove: At the time this happens, the Network Server code has not yet created a socket, so a remote attacker can't connect -> q.e.d. > These two statements contradict each other,... I'm talking about two completely different things here: One talks about taking the code from the Derby project unmodified and the other talks about a developer building their own Derby server. My argument is that there is no additional vulnerability if you allow any JAR name, it just makes an existing vulnerability more visible (so people who are concerned will know about it and can plan against it). This existing vulnerability can't be closed by enforcing a specific JAR name, so it doesn't matter what the name is and where it comes from. So far, you have failed to come up with a convincing argument why my argument is wrong. If you insist that there might be additional vulnerabilities, list them one by one. Talking "grand" when we try to find a way to patch a bug is not helping. At the end of the day, the software must work and it must be as secure as we can make it; no more and no less. > Network server demands a file called "derbynet.jar" in classpath > > > Key: DERBY-3083 > URL: https://issues.apache.org/jira/browse/DERBY-3083 > Project: Derby > Issue Type: Bug > Components: Tools >Affects Versions: 10.3.1.4 >Reporter: Aaron Digulla > Attachments: derby-3083-01-requireDerbynet-aa.diff, > derby-3083-01-requireDerbynet-ab.diff, derby-716-10-datatypesCollation-aa.diff > > > The network server will not start if the derbynet jar is added under a > different name than "derbynet.jar" to the classpath. This makes it impossible > to use it in maven projects where the jar is renamed to > "derbynet-10.3.1.4.jar". > This did work with 10.2.2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3191) SQL roles: add upgrade support
[ https://issues.apache.org/jira/browse/DERBY-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik resolved DERBY-3191. -- Resolution: Fixed Fix Version/s: 10.4.0.0 Committed DERBY-3191b as svn 597409, resolving. > SQL roles: add upgrade support > -- > > Key: DERBY-3191 > URL: https://issues.apache.org/jira/browse/DERBY-3191 > Project: Derby > Issue Type: Improvement >Reporter: Dag H. Wanvik >Assignee: Dag H. Wanvik > Fix For: 10.4.0.0 > > Attachments: DERBY-3191.diff, DERBY-3191.stat, DERBY-3191b.diff, > DERBY-3191b.stat > > > Derby roles introduce a new system catalog (SYSROLES). When a database > is hard upgraded, this catalog needs to be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (DERBY-3190) New simple demo suitable for supported Java ME platforms
[ https://issues.apache.org/jira/browse/DERBY-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John H. Embretsen reopened DERBY-3190: -- Reopening to fix a small issue with a SimpleMobileApp javadoc comment. > New simple demo suitable for supported Java ME platforms > > > Key: DERBY-3190 > URL: https://issues.apache.org/jira/browse/DERBY-3190 > Project: Derby > Issue Type: New Feature > Components: Demos/Scripts >Affects Versions: 10.4.0.0 > Environment: Java ME / J2ME > CDC / Foundation 1.1 >Reporter: John H. Embretsen >Assignee: John H. Embretsen > Fix For: 10.3.1.5, 10.4.0.0 > > Attachments: d3190-v01.diff, readme.html > > > DERBY-2216 added J2ME (Java ME) support in the simple demo (SimpleApp), but > broke the basic client functionality of the demo (at least in some VMs). > Since DERBY-3187 fixes this by removing Java ME support from SimpleApp, a > separate simple demo for Java ME should be included along with the other > demos available in Derby distributions. > Currently supported Java ME platforms are Java ME Virtual Machines with > Connected Device Configuration (CDC) support and the Foundation Profile 1.1 > or better, with the optional package for JDBC (JSR-169). > The new demo should be easy to use and understand, and should be well > commented. The demo code should demonstrate how to create and connect to a > Derby database in a valid Java ME environment, and perform some basic > database operations (insert, update, query). A readme file describing the > demo (and instructions for building and running it) should be included. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3137) SQL roles: add catalog support
[ https://issues.apache.org/jira/browse/DERBY-3137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik resolved DERBY-3137. -- Resolution: Fixed Fix Version/s: 10.4.0.0 Derby Info: (was: [Patch Available]) > SQL roles: add catalog support > -- > > Key: DERBY-3137 > URL: https://issues.apache.org/jira/browse/DERBY-3137 > Project: Derby > Issue Type: New Feature > Components: SQL >Reporter: Dag H. Wanvik >Assignee: Dag H. Wanvik > Fix For: 10.4.0.0 > > Attachments: DERBY-3137-2.diff, DERBY-3137-2.stat, DERBY-3137-2.txt, > DERBY-3137.diff, DERBY-3137.diff, DERBY-3137.stat, DERBY-3137.txt > > > As a next step after adding support for the roles syntax, I intend to > make a patch which implements catalog support for roles, > cf. SYS.SYSROLES described in the specification (attached to > DERBY-2207). Also the patch should tie this support up to the parser > support, so the role statements can be executed. Any privileges > granted to roles would still have no effect at run-time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3223) SQL roles: make use of privileges granted to roles in actual privilege checking
SQL roles: make use of privileges granted to roles in actual privilege checking --- Key: DERBY-3223 URL: https://issues.apache.org/jira/browse/DERBY-3223 Project: Derby Issue Type: New Feature Components: Security, SQL Reporter: Dag H. Wanvik Assignee: Dag H. Wanvik -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2212) Add "Unique where not null" to create index
[ https://issues.apache.org/jira/browse/DERBY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544809 ] Øystein Grøvlen commented on DERBY-2212: Thanks, for the updated func spec, Anurag. I agree with the others who have commented that it would be good if you also include some implementation notes in your spec. I do not see that you have addressed my previous comments from Oct 31: - I would still like that you explicitly state whether you propose to keep the existing behavior for unique index. - I still have a hard time understanding the section on hard upgrade. What do you mean by "No update will be required ..."? Update of what? What is the difference between what is stated in the second sentence and in the first part of the third sentence? Some comments on the test case section: - I also think you should test updates that change column values to/from null, not just inserts. - I do not understand what you mean by testing "null ordering of unique constraints". - I would think adding of not null constraints also need to be tested. - You will probably also need some upgrade tests. > Add "Unique where not null" to create index > --- > > Key: DERBY-2212 > URL: https://issues.apache.org/jira/browse/DERBY-2212 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.2.1.6 >Reporter: Oleksandr Alesinskyy >Assignee: Anurag Shekhar > Attachments: derby-2212preview.diff, derby-2212preview2.diff, > FunctionalSpec.html, FunctionalSpecV3.html, FunctionalSpecV3_comment.html, > FunctionlaSpecv2.html > > > Derby prohibits creation of unique constraints on nullable colums (as well if > only some columns in the constraint list are nullable) and treat nulls in > unique indexes as normal values (i.e. only one row with null values in > indexed columns may be inserted into the table). This bahavior is very > restrictive, does not completely comply with SQL standards (both letter and > intent) as well as with business needs and intending meaning of NULL values > (2 null values are not considered as equal, this comparision shall return > NULL, and for selection criteria boolean null is treated as FALSE). > This behavior, as far as I can see, is modelled after DB2 (and differs from > behavior of most other major databases, like SyBase, Oracle, etc.). > But even DB2 provide some means to alleviate these restrictions, namely > "UNIQUE WHERE NOT NULL" clause for CREATE INDEX statement. > It will be very good if such "UNIQUE WHERE NOT NULL" clause will be > introduced in Derby. > Regards, > Oleksandr Alesinskyy -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3190) New simple demo suitable for supported Java ME platforms
[ https://issues.apache.org/jira/browse/DERBY-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John H. Embretsen updated DERBY-3190: - Attachment: d3190-minorfix.diff Attached d3190-minorfix.diff. M java/demo/simplemobile/readme.html M java/demo/simplemobile/SimpleMobileApp.java This is a patch fixing the mistake of saying that one needs to include the compiled class in the classpath when re-compiling, in the class Javadoc for SimpleMobileApp. Also adding the id attribute to named anchors in readme.html, a trick that prevents these page-internal anchors to change appearance when hovering in a CSS2-enabled browser iff the patch for DERBY-3118 is committed (in any case it doesn't hurt having the attributes there). Any committers willing to check this in to trunk and 10.3 before Monday? Thanks... > New simple demo suitable for supported Java ME platforms > > > Key: DERBY-3190 > URL: https://issues.apache.org/jira/browse/DERBY-3190 > Project: Derby > Issue Type: New Feature > Components: Demos/Scripts >Affects Versions: 10.4.0.0 > Environment: Java ME / J2ME > CDC / Foundation 1.1 >Reporter: John H. Embretsen >Assignee: John H. Embretsen > Fix For: 10.3.1.5, 10.4.0.0 > > Attachments: d3190-minorfix.diff, d3190-v01.diff, readme.html > > > DERBY-2216 added J2ME (Java ME) support in the simple demo (SimpleApp), but > broke the basic client functionality of the demo (at least in some VMs). > Since DERBY-3187 fixes this by removing Java ME support from SimpleApp, a > separate simple demo for Java ME should be included along with the other > demos available in Derby distributions. > Currently supported Java ME platforms are Java ME Virtual Machines with > Connected Device Configuration (CDC) support and the Foundation Profile 1.1 > or better, with the optional package for JDBC (JSR-169). > The new demo should be easy to use and understand, and should be well > commented. The demo code should demonstrate how to create and connect to a > Derby database in a valid Java ME environment, and perform some basic > database operations (insert, update, query). A readme file describing the > demo (and instructions for building and running it) should be included. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3190) New simple demo suitable for supported Java ME platforms
[ https://issues.apache.org/jira/browse/DERBY-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John H. Embretsen updated DERBY-3190: - Derby Info: [Patch Available] > New simple demo suitable for supported Java ME platforms > > > Key: DERBY-3190 > URL: https://issues.apache.org/jira/browse/DERBY-3190 > Project: Derby > Issue Type: New Feature > Components: Demos/Scripts >Affects Versions: 10.4.0.0 > Environment: Java ME / J2ME > CDC / Foundation 1.1 >Reporter: John H. Embretsen >Assignee: John H. Embretsen > Fix For: 10.3.1.5, 10.4.0.0 > > Attachments: d3190-minorfix.diff, d3190-v01.diff, readme.html > > > DERBY-2216 added J2ME (Java ME) support in the simple demo (SimpleApp), but > broke the basic client functionality of the demo (at least in some VMs). > Since DERBY-3187 fixes this by removing Java ME support from SimpleApp, a > separate simple demo for Java ME should be included along with the other > demos available in Derby distributions. > Currently supported Java ME platforms are Java ME Virtual Machines with > Connected Device Configuration (CDC) support and the Foundation Profile 1.1 > or better, with the optional package for JDBC (JSR-169). > The new demo should be easy to use and understand, and should be well > commented. The demo code should demonstrate how to create and connect to a > Derby database in a valid Java ME environment, and perform some basic > database operations (insert, update, query). A readme file describing the > demo (and instructions for building and running it) should be included. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Running suites.All on the phoneME platform
Hi, I'm trying to run suites.All on the phoneME advanced platform. I've compiled my own cvm for foundation profile 1.1, with the optional jsr169 jdbc support. The first hurdle I've struck is that I get a MalformedURLException saying "unknown protocol: https". It seems that some SSL support is missing, and I wasn't immediately able to find out how to add it. The line in the test code that causes problems for me is: static final String OLD_JAR_URL = "https://svn.apache.org/repos/asf/db/derby/jars";; in org.apache.derbyTesting.functionTests.tests.upgradeTests._Suite. When I change this URL to "http" I am able to start the test. Is there a reason this has to be "https"? I seem to be able to access that URL fine in my browser when i change it to "http". Vemund
Failure in lang/compressTable.sql with current 10.3 branch
Hi all, I'm seeing a failure in lang/compressTable.sql with the current 10.3 branch. Is anyone else seeing this? The diff appears to involve a slight difference in the value of the last column in the SYS.SYSSTATISTICS catalog. Here's a snip from compressTable.tmpmstr: create index t2i1 on derby737table2(c1); 0 rows inserted/updated/deleted ij> select * from sys.sysstatistics; STATID |REFERENCEID |TABLEID |CREATIONTIMESTAMP |&|VALID|COLCOUNT |STATISTICS -- FILTERED-UUID|FILTERED-UUID|FILTERED-UUID|xxFILTERED-TIMESTAMPx|I|true |1 |numunique= & And here's the equivalent section of my compressTable.out: create index t2i1 on derby737table2(c1); 0 rows inserted/updated/deleted ij> select * from sys.sysstatistics; STATID |REFERENCEID |TABLEID |CREATIONTIMESTAMP |&|VALID|COLCOUNT |STATISTICS - FILTERED-UUID|FILTERED-UUID|FILTERED-UUID|xxFILTERED-TIMESTAMPx|I|true |1 |numunique= 2 n& This diff appears to occur in all the SYS.SYSSTATISTICS references in the DERBY-737 section of compressTable.sql. Does anyone have a suggestion as to what might be causing this? thanks, bryan
[jira] Closed: (DERBY-3187) SimpleApp (demo) does not work in a client setting
[ https://issues.apache.org/jira/browse/DERBY-3187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John H. Embretsen closed DERBY-3187. Verified the commit, and that SImpleApp now works in a pure client setting in 10.3. Case closed. > SimpleApp (demo) does not work in a client setting > -- > > Key: DERBY-3187 > URL: https://issues.apache.org/jira/browse/DERBY-3187 > Project: Derby > Issue Type: Sub-task > Components: Demos/Scripts >Affects Versions: 10.3.1.4 > Environment: derbyclient (no derby.jar in the classpath) >Reporter: John H. Embretsen >Assignee: John H. Embretsen > Fix For: 10.3.1.5, 10.4.0.0 > > Attachments: d3187-v01.diff > > > Since J2ME support was added to the simple demo (bin-releases: > demo/programs/simple/SimpleApp.java) in DERBY-2216 (first available in > 10.3.1.4), the demo has not worked in a pure client setting as described in > the documentation (bin-releases: demo/programs/simple/example.html). This is > a regression from 10.2.2.0. > $ export CLASSPATH=.:$DERBY_INSTALL/lib/derbyclient.jar > $ cd $DERBY_INSTALL/demo/programs/simple > 10.2.2.0: > $ java SimpleApp derbyclient > SimpleApp starting in derbyclient mode. > Loaded the appropriate driver. > Connected to and created database derbyDB > Created table derbyDB > Inserted 1956 Webster > Inserted 1910 Union > Updated 1956 Webster to 180 Grand > Updated 180 Grand to 300 Lakeshore > Verified the rows > Dropped table derbyDB > Closed result set and statement > Committed transaction and closed connection > SimpleApp finished > 10.3.1.4: > $ java SimpleApp derbyclient > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/derby/jdbc/EmbeddedSimpleDataSource -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3192) Cache session data in the client driver
[ https://issues.apache.org/jira/browse/DERBY-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544840 ] Dyre Tjeldvoll commented on DERBY-3192: --- Hi Knut, thank you for comments. You have valid points and I plan to address them soon. Wrt. to JSR-169; I think all test cases depend on at least one stored procedure that uses DriverManager (verifyCachedIsolation(), which is used by all test cases, use such a stored procedure). So what is the best way of disabling the entire test when running with JSR-169? I guess I could let suite() return only the C/S decorated suite, since functionality being tested only is used in C/S mode, but perhaps there is a more suitable way? > Cache session data in the client driver > --- > > Key: DERBY-3192 > URL: https://issues.apache.org/jira/browse/DERBY-3192 > Project: Derby > Issue Type: Improvement > Components: JDBC, Network Client, Network Server, Performance, SQL >Affects Versions: 10.3.1.4 >Reporter: Dyre Tjeldvoll >Assignee: Dyre Tjeldvoll > Attachments: derby-3192-test.v1.diff, derby-3192-test.v1.stat > > > The reason for doing this is to avoid a rather > substantial performance hit observed when the client driver is used > together with an appserver that uses connection pooling. There are two > problems: > 1) The connection pool will compare the isolation level it has > stored for the connection with the value returned from > Connection.getTransactionIsolation() each and every time someone > requests a new connection from the pool. > 2) The users of the connection pool (ab)use it to avoid having to keep > track of their current connection. So each time a query needs to be > executed a call to the connection pool's getConnection() method is > made. Getting a connection from the connection pool like this also > means that a new PreparedStatement must be prepared each time. > The net result is that each query results in the following sequence: > getConnection() > getTransactionIsolation() --> roundtrip + lookup in server's statement cache > prepareStatment() --> roundtrip + lookup in server's statement cache > executeQuery()--> roundtrip > Arguably this is a "user error" but when suggesting this I'm kindly > informed that this works "just fine" with other datbases (such as > PostgreSQL and ORACLE). > The reason why it works is that these databases do statement caching > in the driver. I've tried to implement a very (too) simple statement > cache in Derby's client driver and to re-enable caching of the > isolation level (see > https://issues.apache.org/jira/browse/DERBY-1148). With these changes > I observe a marked performance improvement when running with appserver > load. > A proper statment cache cannot be implemented without knowing what the > current schema is. If the current schema has changed since the > statement was prepared, it is no longer valid and must be evicted from > the cache. > The problem with caching both the isolation level and the current schema in > the driver is that both can change on the server without the client > detecting it (through SQL and XA and possibly stored procedures). > I think this problem can be overcome if we piggy-back the information we > would > like to cache on messages going back to the client. This can be done by > utilizing the EXCSQLSET DRDA command. According to the DRDA spec (v4, volume > 3, > page 359-360) it is possible to add one or more SQLSTT objects after SQLCARD > in the reply, > I think it would be possible to cache additional session information when > this becomes relevant. It > would also be possible to use EXCSQLSET to batch session state changes > going from the client to the server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3192) Cache session data in the client driver
[ https://issues.apache.org/jira/browse/DERBY-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544842 ] Knut Anders Hatlen commented on DERBY-3192: --- You could wrap the adding of tests in the suite() method with "if (JDBC.vmSupportsJDBC3()) ...", so that it only returns an empty test suite for JSR-169. It seems like other tests that don't run under JSR-169 additionally add themselves to the main test suite from inside a similar if statement in jdbcapi._Suite.suite(). > Cache session data in the client driver > --- > > Key: DERBY-3192 > URL: https://issues.apache.org/jira/browse/DERBY-3192 > Project: Derby > Issue Type: Improvement > Components: JDBC, Network Client, Network Server, Performance, SQL >Affects Versions: 10.3.1.4 >Reporter: Dyre Tjeldvoll >Assignee: Dyre Tjeldvoll > Attachments: derby-3192-test.v1.diff, derby-3192-test.v1.stat > > > The reason for doing this is to avoid a rather > substantial performance hit observed when the client driver is used > together with an appserver that uses connection pooling. There are two > problems: > 1) The connection pool will compare the isolation level it has > stored for the connection with the value returned from > Connection.getTransactionIsolation() each and every time someone > requests a new connection from the pool. > 2) The users of the connection pool (ab)use it to avoid having to keep > track of their current connection. So each time a query needs to be > executed a call to the connection pool's getConnection() method is > made. Getting a connection from the connection pool like this also > means that a new PreparedStatement must be prepared each time. > The net result is that each query results in the following sequence: > getConnection() > getTransactionIsolation() --> roundtrip + lookup in server's statement cache > prepareStatment() --> roundtrip + lookup in server's statement cache > executeQuery()--> roundtrip > Arguably this is a "user error" but when suggesting this I'm kindly > informed that this works "just fine" with other datbases (such as > PostgreSQL and ORACLE). > The reason why it works is that these databases do statement caching > in the driver. I've tried to implement a very (too) simple statement > cache in Derby's client driver and to re-enable caching of the > isolation level (see > https://issues.apache.org/jira/browse/DERBY-1148). With these changes > I observe a marked performance improvement when running with appserver > load. > A proper statment cache cannot be implemented without knowing what the > current schema is. If the current schema has changed since the > statement was prepared, it is no longer valid and must be evicted from > the cache. > The problem with caching both the isolation level and the current schema in > the driver is that both can change on the server without the client > detecting it (through SQL and XA and possibly stored procedures). > I think this problem can be overcome if we piggy-back the information we > would > like to cache on messages going back to the client. This can be done by > utilizing the EXCSQLSET DRDA command. According to the DRDA spec (v4, volume > 3, > page 359-360) it is possible to add one or more SQLSTT objects after SQLCARD > in the reply, > I think it would be possible to cache additional session information when > this becomes relevant. It > would also be possible to use EXCSQLSET to batch session state changes > going from the client to the server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (19 issues) Subscriber: derby-dev Key Summary DERBY-3190 New simple demo suitable for supported Java ME platforms https://issues.apache.org/jira/browse/DERBY-3190 DERBY-3083 Network server demands a file called "derbynet.jar" in classpath https://issues.apache.org/jira/browse/DERBY-3083 DERBY-3220 (ReferencingClause) in CREATE TRIGGER statement not SQL compliant https://issues.apache.org/jira/browse/DERBY-3220 DERBY-3142 sysinfo ignores derby.ui.locale https://issues.apache.org/jira/browse/DERBY-3142 DERBY-3118 Simple demo is out of date https://issues.apache.org/jira/browse/DERBY-3118 DERBY-2352 Assertion Failure with order by and group by expression https://issues.apache.org/jira/browse/DERBY-2352 DERBY-3203 Convert jdbcapi/statementJdbc20.java to JUnit https://issues.apache.org/jira/browse/DERBY-3203 DERBY-2807 Create a test for BlobClob compatibility on Derby server versions vs. Derby client versions. https://issues.apache.org/jira/browse/DERBY-2807 DERBY-3211 Convert derbynet/NSinSameJVM.java to junit https://issues.apache.org/jira/browse/DERBY-3211 DERBY-3117 Adjust master build script to require the Java 5 compiler to build Derby https://issues.apache.org/jira/browse/DERBY-3117 DERBY-2905 Shutting down embedded Derby does not remove all code, the AutoloadDriver is left registered in the DriverManager. https://issues.apache.org/jira/browse/DERBY-2905 DERBY-3184 Replication: Connection attempts to a database in slave mode must fail https://issues.apache.org/jira/browse/DERBY-3184 DERBY-1272 Change sysinfo to print to error log (derby.log) on boot of derby if derby.stream.error.logSeverityLevel=0 https://issues.apache.org/jira/browse/DERBY-1272 DERBY-2815 ij doesn't start with J2ME / JSR169 / weme6.1 because attempting to find java.sql.Driver if ij.protocol property is specified https://issues.apache.org/jira/browse/DERBY-2815 DERBY-2760 Clean-up issues for UTF8Util.java https://issues.apache.org/jira/browse/DERBY-2760 DERBY-2953 Dump the information about rollbacks of the global transaction (introduced in DERBY-2220 and DERBY-2432) to derby.log https://issues.apache.org/jira/browse/DERBY-2953 DERBY-3069 Derby does not resolve functions bound to methods with varargs. https://issues.apache.org/jira/browse/DERBY-3069 DERBY-2182 Documentation for derby.system.bootAll is missing https://issues.apache.org/jira/browse/DERBY-2182 DERBY-2798 A new approach for main-memory database https://issues.apache.org/jira/browse/DERBY-2798
Regression Test Report - Daily 597146 - Sun DBTG
[Auto-generated mail] *Daily* 597146/2007-11-21 18:00:12 CET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 0282282 072.73% derbyall 099199919 0 1198.33% suitesAll linN+1 0282282 0 .% derbyall 099199919 0 .% suitesAll sles 0282282 071.93% derbyall 099199919 0 747.86% suitesAll sol 0282282 077.07% derbyall 099199919 0 1240.36% suitesAll solN+1 NA NA NANA derbyall NA NA NANA suitesAll sparc 0282282 067.34% derbyall F:0,E:199199918 0 313.10% suitesAll vista 0282282 0 .% derbyall 089828982 0 390.30% suitesAll w2003 0282282 0 .% derbyall 089828982 0 218.90% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-597146.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/597146_bySig.html *Jvm: 1.5* lin 0283283 072.57% derbyall F:0,E:182038202 0 794.29% suitesAll linN+1 0283283 0 .% derbyall F:0,E:182038202 0 .% suitesAll sles 0283283 071.67% derbyall 082038203 0 515.52% suitesAll sol 0283283 081.25% derbyall 082038203 0 756.62% suitesAll solN+1 0283283 088.85% derbyall 082038203 0 717.43% suitesAll sparc 0283283 068.00% derbyall 082038203 0 602.13% suitesAll vista 0283283 071.88% derbyall 072667266 0 361.48% suitesAll w2003 0283283 075.51% derbyall 072667266 0 236.74% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-597146.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/597146_bySig.html *Jvm: 1.4* lin 0280280 273.85% derbyall 081518151 0 721.80% suitesAll linN+1 0280280 2 .% derbyall 081518151 0 .% suitesAll sles 0280280 271.06% derbyall 081518151 0 478.03% suitesAll sol 0280280 278.58% derbyall 081518151 0 605.26% suitesAll solN+1 1280279 291.53% derbyall NA NA NANA suitesAll sparc 0280280 268.54% derbyall 081518151 0 610.01% suitesAll vista 0280280 2 .% derbyall F:2,E:072147212 0 348.66% suitesAll w2003 0280280 2 .% derbyall 072147214 0 .% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-597146.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/597146_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/597146.txt ( All results in http://dbtg.thresher.com/derby/test/ )
Re: Running suites.All on the phoneME platform
On 11/22/07, Vemund Ostgaard <[EMAIL PROTECTED]> wrote: > Hi, I'm trying to run suites.All on the phoneME advanced platform. I've > compiled my own cvm for foundation profile 1.1, with the optional jsr169 > jdbc support. > > The first hurdle I've struck is that I get a MalformedURLException > saying "unknown protocol: https". It seems that some SSL support is > missing, and I wasn't immediately able to find out how to add it. The > line in the test code that causes problems for me is: > >static final String OLD_JAR_URL = >"https://svn.apache.org/repos/asf/db/derby/jars";; > > in org.apache.derbyTesting.functionTests.tests.upgradeTests._Suite. > > When I change this URL to "http" I am able to start the test. Is there a > reason this has to be "https"? I seem to be able to access that URL fine > in my browser when i change it to "http". > > > Vemund > I don't think this needs to be https. I modified the _Suite.java with revision 597467. If I was wrong, it can be changed back. Myrna
Re: Running suites.All on the phoneME platform
On 11/22/07, Myrna van Lunteren <[EMAIL PROTECTED]> wrote: > On 11/22/07, Vemund Ostgaard <[EMAIL PROTECTED]> wrote: > > Hi, I'm trying to run suites.All on the phoneME advanced platform. I've > > compiled my own cvm for foundation profile 1.1, with the optional jsr169 > > jdbc support. > > > > The first hurdle I've struck is that I get a MalformedURLException > > saying "unknown protocol: https". It seems that some SSL support is > > missing, and I wasn't immediately able to find out how to add it. The > > line in the test code that causes problems for me is: > > > >static final String OLD_JAR_URL = > >"https://svn.apache.org/repos/asf/db/derby/jars";; > > > > in org.apache.derbyTesting.functionTests.tests.upgradeTests._Suite. > > > > When I change this URL to "http" I am able to start the test. Is there a > > reason this has to be "https"? I seem to be able to access that URL fine > > in my browser when i change it to "http". > > > > > > Vemund > > > I don't think this needs to be https. > I modified the _Suite.java with revision 597467. If I was wrong, it > can be changed back. > > Myrna > I should also mention, that if you intend to run the upgrade tests (ir)regularly, you should download the old versions' derby.jar files and start the upgrade suite with -DderbyTesting.oldReleasePath= Sorry for the nag. Myrna
[jira] Commented: (DERBY-3211) Convert derbynet/NSinSameJVM.java to junit
[ https://issues.apache.org/jira/browse/DERBY-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544855 ] Myrna van Lunteren commented on DERBY-3211: --- I thought the latest patch looked good, and as there were no further comments, I committed it to trunk with revision 597456, and removed the old test and masters etc. with revision 597466. I intend to backport this to 10.3 - tomorrow. > Convert derbynet/NSinSameJVM.java to junit > -- > > Key: DERBY-3211 > URL: https://issues.apache.org/jira/browse/DERBY-3211 > Project: Derby > Issue Type: Test >Reporter: Manjula Kutty >Assignee: Manjula Kutty >Priority: Minor > Attachments: DERBY-3211_diff_11_16.txt, DERBY-3211_diff_11_19.txt, > DERBY-3211_diff_11_19_ver2.txt, DERBY-3211_stat_11_16.txt, > DERBY-3211_stat_11_19.txt, DERBY-3211_stat_11_19_ver2.txt > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3064) Implement the LogShipper that will enable the shipping of Log records from the master to the slave
[ https://issues.apache.org/jira/browse/DERBY-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3064: --- Attachment: LogShipperIntegration_v3.stat LogShipperIntegration_v3.diff In this patch * I have addressed the issues pointed out with respect to logging in the MasterController. * I have followed the same pattern as in SlaveController in extending the ReplicationLogger and using the logError method. I however thought it would have been better to have had logError as a static method in the ReplicationLogger class rather than extending the class into the controllers. I decided not to disturb the structure of the classes for now. I have not run tests on the patch. I shall run the tests and shall revert back. > Implement the LogShipper that will enable the shipping of Log records from > the master to the slave > -- > > Key: DERBY-3064 > URL: https://issues.apache.org/jira/browse/DERBY-3064 > Project: Derby > Issue Type: Sub-task > Components: Miscellaneous >Reporter: V.Narayanan >Assignee: V.Narayanan > Attachments: LogShipperImpl_v1.diff, LogShipperImpl_v1.stat, > LogShipperImpl_v2.diff, LogShipperImpl_v2.stat, LogShipperImpl_v3.diff, > LogShipperImpl_v3.stat, LogShipperImpl_v4.diff, LogShipperImpl_v4.stat, > LogShipperImpl_v5.diff, LogShipperImpl_v5.stat, > LogShipperIntegration_v1.diff, LogShipperIntegration_v1.stat, > LogShipperIntegration_v2.diff, LogShipperIntegration_v2.stat, > LogShipperIntegration_v3.diff, LogShipperIntegration_v3.stat > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3211) Convert derbynet/NSinSameJVM.java to junit
[ https://issues.apache.org/jira/browse/DERBY-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Myrna van Lunteren updated DERBY-3211: -- Derby Info: (was: [Patch Available]) > Convert derbynet/NSinSameJVM.java to junit > -- > > Key: DERBY-3211 > URL: https://issues.apache.org/jira/browse/DERBY-3211 > Project: Derby > Issue Type: Test >Reporter: Manjula Kutty >Assignee: Manjula Kutty >Priority: Minor > Attachments: DERBY-3211_diff_11_16.txt, DERBY-3211_diff_11_19.txt, > DERBY-3211_diff_11_19_ver2.txt, DERBY-3211_stat_11_16.txt, > DERBY-3211_stat_11_19.txt, DERBY-3211_stat_11_19_ver2.txt > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3192) Cache session data in the client driver
[ https://issues.apache.org/jira/browse/DERBY-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll updated DERBY-3192: -- Attachment: derby-3192-test.fup1.diff I attached .fup1.diff which addresses Knut's comments. > Cache session data in the client driver > --- > > Key: DERBY-3192 > URL: https://issues.apache.org/jira/browse/DERBY-3192 > Project: Derby > Issue Type: Improvement > Components: JDBC, Network Client, Network Server, Performance, SQL >Affects Versions: 10.3.1.4 >Reporter: Dyre Tjeldvoll >Assignee: Dyre Tjeldvoll > Attachments: derby-3192-test.fup1.diff, derby-3192-test.v1.diff, > derby-3192-test.v1.stat > > > The reason for doing this is to avoid a rather > substantial performance hit observed when the client driver is used > together with an appserver that uses connection pooling. There are two > problems: > 1) The connection pool will compare the isolation level it has > stored for the connection with the value returned from > Connection.getTransactionIsolation() each and every time someone > requests a new connection from the pool. > 2) The users of the connection pool (ab)use it to avoid having to keep > track of their current connection. So each time a query needs to be > executed a call to the connection pool's getConnection() method is > made. Getting a connection from the connection pool like this also > means that a new PreparedStatement must be prepared each time. > The net result is that each query results in the following sequence: > getConnection() > getTransactionIsolation() --> roundtrip + lookup in server's statement cache > prepareStatment() --> roundtrip + lookup in server's statement cache > executeQuery()--> roundtrip > Arguably this is a "user error" but when suggesting this I'm kindly > informed that this works "just fine" with other datbases (such as > PostgreSQL and ORACLE). > The reason why it works is that these databases do statement caching > in the driver. I've tried to implement a very (too) simple statement > cache in Derby's client driver and to re-enable caching of the > isolation level (see > https://issues.apache.org/jira/browse/DERBY-1148). With these changes > I observe a marked performance improvement when running with appserver > load. > A proper statment cache cannot be implemented without knowing what the > current schema is. If the current schema has changed since the > statement was prepared, it is no longer valid and must be evicted from > the cache. > The problem with caching both the isolation level and the current schema in > the driver is that both can change on the server without the client > detecting it (through SQL and XA and possibly stored procedures). > I think this problem can be overcome if we piggy-back the information we > would > like to cache on messages going back to the client. This can be done by > utilizing the EXCSQLSET DRDA command. According to the DRDA spec (v4, volume > 3, > page 359-360) it is possible to add one or more SQLSTT objects after SQLCARD > in the reply, > I think it would be possible to cache additional session information when > this becomes relevant. It > would also be possible to use EXCSQLSET to batch session state changes > going from the client to the server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3190) New simple demo suitable for supported Java ME platforms
[ https://issues.apache.org/jira/browse/DERBY-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Myrna van Lunteren resolved DERBY-3190. --- Resolution: Fixed Derby Info: (was: [Patch Available]) The changes of the minor patch look ok to me, I committed them to trunk with revision 597475 and to 10.3 with revision 597476. > New simple demo suitable for supported Java ME platforms > > > Key: DERBY-3190 > URL: https://issues.apache.org/jira/browse/DERBY-3190 > Project: Derby > Issue Type: New Feature > Components: Demos/Scripts >Affects Versions: 10.4.0.0 > Environment: Java ME / J2ME > CDC / Foundation 1.1 >Reporter: John H. Embretsen >Assignee: John H. Embretsen > Fix For: 10.3.1.5, 10.4.0.0 > > Attachments: d3190-minorfix.diff, d3190-v01.diff, readme.html > > > DERBY-2216 added J2ME (Java ME) support in the simple demo (SimpleApp), but > broke the basic client functionality of the demo (at least in some VMs). > Since DERBY-3187 fixes this by removing Java ME support from SimpleApp, a > separate simple demo for Java ME should be included along with the other > demos available in Derby distributions. > Currently supported Java ME platforms are Java ME Virtual Machines with > Connected Device Configuration (CDC) support and the Foundation Profile 1.1 > or better, with the optional package for JDBC (JSR-169). > The new demo should be easy to use and understand, and should be well > commented. The demo code should demonstrate how to create and connect to a > Derby database in a valid Java ME environment, and perform some basic > database operations (insert, update, query). A readme file describing the > demo (and instructions for building and running it) should be included. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3119) Derby does not resolve functions to methods with Integer return type.
[
https://issues.apache.org/jira/browse/DERBY-3119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544868
]
James F. Adams commented on DERBY-3119:
---
Would it be possible for someone to merge this to the 10.3 branch?
> Derby does not resolve functions to methods with Integer return type.
> -
>
> Key: DERBY-3119
> URL: https://issues.apache.org/jira/browse/DERBY-3119
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0,
> 10.3.1.4
>Reporter: Rick Hillegas
>Assignee: James F. Adams
> Fix For: 10.4.0.0
>
> Attachments: derby-3119-1_diff.txt
>
>
> Derby can bind a function invocation to a method which returns int but not to
> a method which returns Integer. I think that both of these resolutions should
> succeed given the rules in the SQL Standard, part 13, section 8.6, syntax
> rule 5, case a, item ii. Here is some code which shows this problem. First a
> class to declare the methods:
> public class zz
> {
> public static int returnsInt()
> {
> return 1;
> }
>
> public static Integer returnsInteger()
> {
> return new Integer( 2 );
> }
>
> }
> The following ij script shows that the int-returning method is resolved but
> not the Integer-returning method:
> ij version 10.4
> ij> connect 'jdbc:derby:derby10.4;create=true';
> WARNING 01J01: Database 'derby10.4' not created, connection made to existing
> database instead.
> ij> drop function returnsInt;
> 0 rows inserted/updated/deleted
> ij> drop function returnsInteger;
> 0 rows inserted/updated/deleted
> ij> create function returnsInt()
> returns int
> language java
> parameter style java
> no sql
> external name 'zz.returnsInt'
> ;
> 0 rows inserted/updated/deleted
> ij> create function returnsInteger()
> returns int
> language java
> parameter style java
> no sql
> external name 'zz.returnsInteger'
> ;
> 0 rows inserted/updated/deleted
> ij> values ( returnsInt() );
> 1
> ---
> 1
> 1 row selected
> ij> values ( returnsInteger() );
> ERROR 42X50: No method was found that matched the method call int
> zz.returnsInteger(), tried all combinations of object and primitive types and
> any possible type conversion for any parameters the method call may have.
> The method might exist but it is not public and/or static, or the parameter
> types are not method invocation convertible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3198) Using setQueryTimeout will leak sections
[ https://issues.apache.org/jira/browse/DERBY-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544883 ] Dyre Tjeldvoll commented on DERBY-3198: --- Based on what I see methods similar to writeSetSpecialRegister do, I think a safe and reasonable way of getting a Section is as follows: 1) If the surrounding code has set the newSection variable, use that. This will usually be the case when writeSetSpecialRegister is used to request session data, as it happens after this variable has been assigned. 2) If Statement.section_ is not null, it is probably safe to use it. 3) if Statement.section_ is null, request a new one from the SectionManager and assign that to section_. Assigning it to section_ will ensure that it is freed later. Doing so does, however, require a change to the signature of the writeSetSpecialRegister() methods in the Net-layer, so that the Section to use can be passed in as a parameter (this seems to be how it is done in other write methods). The change is necessary because the decision about which Section to use need to happen in the am-layer. It cannot be done in NetStatementRequest as it currently is, because there we don't have access to the Section variables mentioned earlier. I'm wondering if the ability to access the SectionManager from the Net-layer is an unintended loophole. Seems like NetStatementReply.writeSetSpecialRegister() is the only place in the net package where it is used. The SectionManager is accessed through a public member in am.Agent which has the following comment: public SectionManager sectionManager_ = null; // temporarily public, make friendly at least !! The Net-layer gets at this member because NetAgent extends am.Agent. > Using setQueryTimeout will leak sections > - > > Key: DERBY-3198 > URL: https://issues.apache.org/jira/browse/DERBY-3198 > Project: Derby > Issue Type: Bug > Components: JDBC, Network Client >Affects Versions: 10.3.1.4 >Reporter: Dyre Tjeldvoll > Attachments: repro.diff > > > The implementation of setQueryTimeout relies on > NetStatementReply.writeSetSpecialRegister() which will allocate a dynamic > section when called. No reference to this Section object is kept, and so > Section.free() never gets called on it. Executing the same statment > repeatedly with a query timeout set results in the client driver throwing an > exception because the number of Sections exceeding 32000. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Running suites.All on the phoneME platform
Myrna van Lunteren wrote: On 11/22/07, Myrna van Lunteren <[EMAIL PROTECTED]> wrote: On 11/22/07, Vemund Ostgaard <[EMAIL PROTECTED]> wrote: Hi, I'm trying to run suites.All on the phoneME advanced platform. I've compiled my own cvm for foundation profile 1.1, with the optional jsr169 jdbc support. The first hurdle I've struck is that I get a MalformedURLException saying "unknown protocol: https". It seems that some SSL support is missing, and I wasn't immediately able to find out how to add it. The line in the test code that causes problems for me is: static final String OLD_JAR_URL = "https://svn.apache.org/repos/asf/db/derby/jars";; in org.apache.derbyTesting.functionTests.tests.upgradeTests._Suite. When I change this URL to "http" I am able to start the test. Is there a reason this has to be "https"? I seem to be able to access that URL fine in my browser when i change it to "http". Vemund I don't think this needs to be https. I modified the _Suite.java with revision 597467. If I was wrong, it can be changed back. Myrna I should also mention, that if you intend to run the upgrade tests (ir)regularly, you should download the old versions' derby.jar files and start the upgrade suite with -DderbyTesting.oldReleasePath= +1 It's also much faster! To do this just check out the jars svn co http://svn.apache.org/repos/asf/db/derby/jars and then point derbyTesting.oldReleasePath to the resulting jars directory. Dan.
Re: Failure in lang/compressTable.sql with current 10.3 branch
Hi Bryan! I also see it in my daily tests on 10.3. Look for instance at http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.4/FailReports/596747_bySig.html It started to appear the 20th of November, so that might help? It appears on all platforms and under all jvm-versions. (see http://dbtg.thresher.com/derby/test/ - 10.3 Branch - daily) Henri Bryan Pendleton wrote: Hi all, I'm seeing a failure in lang/compressTable.sql with the current 10.3 branch. Is anyone else seeing this? The diff appears to involve a slight difference in the value of the last column in the SYS.SYSSTATISTICS catalog. Here's a snip from compressTable.tmpmstr: create index t2i1 on derby737table2(c1); 0 rows inserted/updated/deleted ij> select * from sys.sysstatistics; STATID |REFERENCEID |TABLEID |CREATIONTIMESTAMP |&|VALID|COLCOUNT |STATISTICS -- FILTERED-UUID|FILTERED-UUID|FILTERED-UUID|xxFILTERED-TIMESTAMPx|I|true |1 |numunique= & And here's the equivalent section of my compressTable.out: create index t2i1 on derby737table2(c1); 0 rows inserted/updated/deleted ij> select * from sys.sysstatistics; STATID |REFERENCEID |TABLEID |CREATIONTIMESTAMP |&|VALID|COLCOUNT |STATISTICS - FILTERED-UUID|FILTERED-UUID|FILTERED-UUID|xxFILTERED-TIMESTAMPx|I|true |1 |numunique= 2 n& This diff appears to occur in all the SYS.SYSSTATISTICS references in the DERBY-737 section of compressTable.sql. Does anyone have a suggestion as to what might be causing this? thanks, bryan
Re: Failure in lang/compressTable.sql with current 10.3 branch
Henri van de Scheur wrote:
Hi Bryan!
I also see it in my daily tests on 10.3. Look for instance at
http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.4/FailReports/596747_bySig.html
It started to appear the 20th of November, so that might help?
It appears on all platforms and under all jvm-versions.
(see http://dbtg.thresher.com/derby/test/ - 10.3 Branch - daily)
Henri
Bryan Pendleton wrote:
Hi all,
I'm seeing a failure in lang/compressTable.sql with the current 10.3
branch.
Is anyone else seeing this?
The diff appears to involve a slight difference in the value of the last
column in the SYS.SYSSTATISTICS catalog.
Here's a snip from compressTable.tmpmstr:
create index t2i1 on derby737table2(c1);
0 rows inserted/updated/deleted
ij> select * from sys.sysstatistics;
STATID
|REFERENCEID |TABLEID
|CREATIONTIMESTAMP |&|VALID|COLCOUNT |STATISTICS
--
FILTERED-UUID|FILTERED-UUID|FILTERED-UUID|xxFILTERED-TIMESTAMPx|I|true
|1 |numunique= &
And here's the equivalent section of my compressTable.out:
create index t2i1 on derby737table2(c1);
0 rows inserted/updated/deleted
ij> select * from sys.sysstatistics;
STATID
|REFERENCEID |TABLEID
|CREATIONTIMESTAMP |&|VALID|COLCOUNT |STATISTICS
-
FILTERED-UUID|FILTERED-UUID|FILTERED-UUID|xxFILTERED-TIMESTAMPx|I|true
|1 |numunique= 2 n&
This diff appears to occur in all the SYS.SYSSTATISTICS references in
the DERBY-737 section of compressTable.sql.
Does anyone have a suggestion as to what might be causing this?
thanks,
bryan
I guess r566353 needs to be backported to 10.3 as well:
11/21/2007 09:11 AM Ole Solberg (JIRA) wrote:
> [
https://issues.apache.org/jira/browse/DERBY-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544189
]
>
> Ole Solberg commented on DERBY-1734:
>
>
> 2007-11-20 nightlies: 10.3 regression tests fails in
lang/CompressTable.sql.
>
> Probably caused by r596490 which includes r564792:
>
> We saw the same with r564792 on trunk. This was fixed by
> r566353 | djd | 2007-08-15 23:45:33 +0200 (Wed, 15 Aug 2007) | 1 line
- Fix compressTable master file.
>
> See e.g.
http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.6/testing/Limited/testSummary-596747.html
> or http://dbtg.thresher.com/derby/test/stats_today.html as of
2007-11-21 (the "-5001" entry).
>
>
>
>
>>Simplify building of SystemColumn array in CatalogRowFactory
implementations.
>>--
>>
>>Key: DERBY-1734
>>URL: https://issues.apache.org/jira/browse/DERBY-1734
>>Project: Derby
>> Issue Type: Sub-task
>> Components: SQL
>> Reporter: Daniel John Debrunner
>> Assignee: Daniel John Debrunner
>> Priority: Minor
>>Fix For: 10.4.0.0
>>
>>
>>The implementations of CatalogRowFactory.buildColumnList() can be
simplified in a number of ways:
>> 1) precision & scale are always passed in as zero and can be removed
>> 2) adding static factory methods to SystemColumnImpl would ease
the building of the arrays by not requiring the additional redundant
arguments the constructor call forces today, e.g. max length i snot
required to create an INTEGER column.
>>3) The column's position is not required to be stored in the
SytstemColumn class, it's defined by the position in the array
>>4) arrays can be built using
>> new SystemColumn[] { ... }
>> syntax instead of the existing
>>columnList[0] = ...
>>columnList[1] = ...
>> or
>>columnList[index++] = ...
>>columnList[index++] = ...
>>
>
>
--
Ole Solberg, Database Technology Group,
Sun Microsystems, Trondheim, Norway
[jira] Assigned: (DERBY-3206) Replication: Add functionality to send various commands from master to slave using the replication network connection
[ https://issues.apache.org/jira/browse/DERBY-3206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan reassigned DERBY-3206: -- Assignee: V.Narayanan > Replication: Add functionality to send various commands from master to slave > using the replication network connection > - > > Key: DERBY-3206 > URL: https://issues.apache.org/jira/browse/DERBY-3206 > Project: Derby > Issue Type: Sub-task > Components: Services >Affects Versions: 10.4.0.0 >Reporter: Jørgen Løland >Assignee: V.Narayanan > > The replication network code can currently be used to send chunks of log > records, error messages and some more. In addition to the existing message > types, we need to send commands from the master to the slave. The following > are at least required; more commands may come up at a later stage: > Type MessageObject > --- > stopSlave Reason why replication is stopped > failover Reason why replication is stopped -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2352) Assertion Failure with order by and group by expression
[
https://issues.apache.org/jira/browse/DERBY-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Pendleton resolved DERBY-2352.
Resolution: Fixed
Fix Version/s: 10.4.0.0
10.3.1.5
Derby Info: (was: [Patch Available])
Merged the change to the 10.3 branch and submitted as revision 597516.
> Assertion Failure with order by and group by expression
> ---
>
> Key: DERBY-2352
> URL: https://issues.apache.org/jira/browse/DERBY-2352
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.2.2.0, 10.3.1.4
> Environment: Any
>Reporter: Yip Ng
>Assignee: Bryan Pendleton
> Fix For: 10.3.1.5, 10.4.0.0
>
> Attachments: substrBind.diff, substrBindWithTests.diff,
> substrBindWithTestsUpdated.diff, substringReturnsChar.diff
>
>
> Assertion failure with order by expression:
> ij> select substr('abc', 1) from t1 order by substr('abc', 1);
> ERROR XJ001: Java exception: 'ASSERT FAILED col1.getClass() (class
> org.apache.derby.iapi.types.SQLVarchar) expected to be the same as
> col2.getClass() (class org.apache.derby.iapi.types.SQLChar):
> org.apache.derby.shared.common.sanity.AssertFailure'.
> Stacktrace:
> org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED
> col1.getClass() (class org.apache.derby.iapi.types.SQLVarchar) expected to be
> the same as col2.getClass() (class org.apache.derby.iapi.types.SQLChar)
> at
> org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:149)
> at
> org.apache.derby.impl.store.access.sort.MergeSort.checkColumnTypes(MergeSort.java:472)
> at
> org.apache.derby.impl.store.access.sort.MergeInserter.insert(MergeInserter.java:106)
> at
> org.apache.derby.impl.sql.execute.SortResultSet.loadSorter(SortResultSet.java:318)
> at
> org.apache.derby.impl.sql.execute.SortResultSet.openCore(SortResultSet.java:269)
> at
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(ProjectRestrictResultSet.java:169)
> at
> org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(BasicNoPutResultSetImpl.java:260)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:358)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1182)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:585)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:517)
> at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:321)
> at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:517)
> at
> org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:370)
> at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:268)
> at org.apache.derby.impl.tools.ij.Main.go(Main.java:204)
> at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:170)
> at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:56)
> at org.apache.derby.tools.ij.main(ij.java:71)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Fwd: A.Word.A.Day--Darby and Joan
Living in Harmony, no doubt. Craig Begin forwarded message: From: Wordsmith <[EMAIL PROTECTED]> Date: November 22, 2007 9:04:14 PM PST To: [EMAIL PROTECTED] Subject: A.Word.A.Day--Darby and Joan This week's theme: eponyms -- words coined after someone. Darby and Joan (DAHR-bee and joan) noun A devoted old couple leading a quiet, uneventful life. [After a couple named in a 18th century poem in The Gentleman's Magazine (London).] In 1735 Henry Woodfall, a printer's apprentice, wrote a ballad titled "The joys of love never forgot: a song" about a happily married elderly couple. His inspiration for those characters was his own boss John Darby and his wife Joan: "Old Darby, with Joan by his side, You've often regarded with wonder: He's dropsical, she is sore-eyed, Yet they're never happy asunder ..." As you can imagine, he wrote this poem after Darby's death. This poem in turn became an inspiration for follow-up poems and eventually Darby and Joan became a metaphor. In the UK, clubs for old people are still called Darby and Joan clubs. -Anu Garg (words at wordsmith.org) "On the shores of holy Lake Manosarovar there is a nameless hotel run by a very elderly couple, a sort of Tibetan Darby and Joan." Karen Swenson; At Tibetan Hotels, Don't Expect the Light To Be Left On; The Wall Street Journal (New York); Dec 4, 2001. This newsletter is made possible in part by these sponsors: Discover new *super magnetic* Thinking Putty. It's the perfect stocking stuffer! Find out more: http://puttyworld.com?a=awad Always find the right word with the Visual Thesaurus. Wordsmith readers save 10%. Try it free! http://www.visualthesaurus.com/?ad=aw&code=m7r Talk turkey and stick your neck out! Try Orijinz, a hilarious new card game about word and phrase origins. A great holiday gift! http:// entspire.com .. .. To be able to destroy with good conscience, to be able to behave badly and call your bad behavior "righteous indignation" -- this is the height of psychological luxury, the most delicious of moral treats. -Aldous Huxley, novelist (1894-1963) Looking for word/quotation archives: http://wordsmith.org/awad/ archives.html Unsubscribe, change address, etc: http://wordsmith.org/awad/ subscriber.html Pronunciation: http://wordsmith.org/words/darby_and_joan.wav http://wordsmith.org/words/darby_and_joan.ram Permalink: http://wordsmith.org/words/darby_and_joan.html This message was sent to "[EMAIL PROTECTED]". Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
