date:20071122

[
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

2007-11-22 Thread JIRA


[ 
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 class.unknown method(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 class.unknown method(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 class.unknown method(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 class.unknown method(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 class.unknown method(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

[jira] Issue Comment Edited: (DERBY-3217) ErrorStreamTest failing on ibm j9 jvm

2007-11-22 Thread JIRA


[ 
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 class.unknown method(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 class.unknown method(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 class.unknown method(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 class.unknown method(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 class.unknown method(Unknown Source)
   at

[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) transition table or variable list (ReferencingClause) in CREATE TRIGGER statement not SQL compliant

2007-11-22 Thread Bernt M. Johnsen (JIRA)


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


 transition table or variable list (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:
 trigger definition ::=
 CREATE TRIGGER trigger name trigger action time trigger event
 ON table name [ REFERENCING transition table or variable list ]
 triggered action
 ...
 transition table or variable ::=
 OLD [ ROW ] [ AS ] old transition variable name
 | NEW [ ROW ] [ AS ] new transition variable name
 | OLD TABLE [ AS ] old transition table name
 | NEW TABLE [ AS ] new transition table name

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

2007-11-22 Thread Ole Solberg (JIRA)

'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)

2007-11-22 Thread Ole Solberg (JIRA)


 [ 
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 class.unknown method(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 class.unknown method(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 class.unknown method(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

[jira] Commented: (DERBY-3220) transition table or variable list (ReferencingClause) in CREATE TRIGGER statement not SQL compliant

2007-11-22 Thread Thomas Nielsen (JIRA)


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




 transition table or variable list (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:
 trigger definition ::=
 CREATE TRIGGER trigger name trigger action time trigger event
 ON table name [ REFERENCING transition table or variable list ]
 triggered action
 ...
 transition table or variable ::=
 OLD [ ROW ] [ AS ] old transition variable name
 | NEW [ ROW ] [ AS ] new transition variable name
 | OLD TABLE [ AS ] old transition table name
 | NEW TABLE [ AS ] new transition table name

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

2007-11-22 Thread Tomohito Nakayama (JIRA)


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

--
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) transition table or variable list (ReferencingClause) in CREATE TRIGGER statement not SQL compliant

2007-11-22 Thread Thomas Nielsen (JIRA)


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



  
 transition table or variable list (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:
 trigger definition ::=
 CREATE TRIGGER trigger name trigger action time trigger event
 ON table name [ REFERENCING transition table or variable list ]
 triggered action
 ...
 transition table or variable ::=
 OLD [ ROW ] [ AS ] old transition variable name
 | NEW [ ROW ] [ AS ] new transition variable name
 | OLD TABLE [ AS ] old transition table name
 | NEW TABLE [ AS ] new transition table name

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

2007-11-22 Thread Aaron Digulla (JIRA)

[
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

2007-11-22 Thread Dag H. Wanvik (JIRA)


 [ 
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

2007-11-22 Thread Dag H. Wanvik (JIRA)


 [ 
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

2007-11-22 Thread Dag H. Wanvik (JIRA)

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

2007-11-22 Thread JIRA

[
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

Attachments: d3190-minorfix.diff, d3190-v01.diff, readme.html

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

2007-11-22 Thread Vemund Ostgaard

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

2007-11-22 Thread Bryan Pendleton


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

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

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

2007-11-22 Thread jira

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  transition table or variable list (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

2007-11-22 Thread Henri . Vandescheur

[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

2007-11-22 Thread Myrna van Lunteren

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

2007-11-22 Thread Myrna van Lunteren

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=/top
dir for oldjar dirs
Sorry for the nag.
Myrna

[jira] Commented: (DERBY-3211) Convert derbynet/NSinSameJVM.java to junit

2007-11-22 Thread Myrna van Lunteren (JIRA)


[ 
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

2007-11-22 Thread V.Narayanan (JIRA)


 [ 
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

2007-11-22 Thread Myrna van Lunteren (JIRA)


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

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

2007-11-22 Thread Myrna van Lunteren (JIRA)

[
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

Attachments: d3190-minorfix.diff, d3190-v01.diff, readme.html

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

2007-11-22 Thread James F. Adams (JIRA)


[ 
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