[jira] Commented: (DERBY-952) DerbyNet/derbynetmats/NSinSameJVM fails on Win XP / Cygwin

[Ole Solberg (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-952?page=comments#action_12425159 ] 

Ole Solberg commented on DERBY-952:
---

I still see this test fail. On Linux and Solaris I was able to bypass the 
failure by patching /etc/hosts. On Win this did not help.


> DerbyNet/derbynetmats/NSinSameJVM fails on Win XP / Cygwin
> --
>
> Key: DERBY-952
> URL: http://issues.apache.org/jira/browse/DERBY-952
> Project: Derby
>  Issue Type: Test
>  Components: Regression Test Failure
>Affects Versions: 10.2.0.0
> Environment: OS:  Microsoft Windows XP Professional - 5.1.2600 
> Service Pack 2 Build 2600, CYGWIN_NT-5.1 1.5.18(0.132/4/2) 2005-07-02 20:30 
> Cygwin
> JVM:  Sun Microsystems Inc. 1.5.0_05
>Reporter: Ole Solberg
> Attachments: derby-952-idea.diff, DERBY-952.diff
>
>
> * Diff file 
> derbyall/derbynetmats/DerbyNet/derbynetmats/NSinSameJVM.diff
> *** Start: NSinSameJVM jdk1.5.0_05 DerbyNet derbynetmats:derbynetmats 
> 2006-02-05 02:01:20 ***
> 3 del
> < main-NSinSameJVM: NetworkServer started
> 4 del
> < main-NSinSameJVM: Connected to database NSinSameJVMTestDB;create=true
> 5 del
> < getting ready to shutdown
> 6 del
> < Shutdown successful.
> 6 add
> > FAIL Network Server did not start
> Test Failed.
> *** End:   NSinSameJVM jdk1.5.0_05 DerbyNet derbynetmats:derbynetmats 
> 2006-02-05 02:02:10 ***
> *
> http://www.multinet.no/~solberg/public/Apache/Derby/testlog/CYGWIN_NT-5.1_i686-unknown/373335-derbynetmats_diff.txt

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1432) derbynetmats/NSinSameJVM.java fails to run due to Warning "UnknkownHostException: dyn" on Linux with DHCP generated hostname

[Ole Solberg (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1432?page=comments#action_12425160 ] 

Ole Solberg commented on DERBY-1432:


Is this the same as http://issues.apache.org/jira/browse/DERBY-952?

> derbynetmats/NSinSameJVM.java fails to run due to Warning 
> "UnknkownHostException: dyn" on Linux with DHCP generated hostname
> 
>
> Key: DERBY-1432
> URL: http://issues.apache.org/jira/browse/DERBY-1432
> Project: Derby
>  Issue Type: Bug
>  Components: Test, Regression Test Failure
>Affects Versions: 10.1.2.1, 10.1.3.0
> Environment: Linux Operating Systems using DHCP IP address *and* 
> hostname generation
>Reporter: Stan Bradbury
>Priority: Minor
>
> The test derbynetmats/NSinSameJVM.java reports that the Network Server failed 
> to start and aborts on Linux machines that use DHCP to generate a hostname 
> that reflects the generated IP address (e.g. hostname like: dyn where 
>  is the IP address string like 216101116144).  Network server does, in 
> fact, start.
> derby.log entry:
> Warning: UnknkownHostException: dyn: dyn.
> Server is ready to accept connections on port .
> derbyall.sum entry:
> > FAIL Network Server did not start
> Test Failed.
> *** End:   NSinSameJVM jdk1.5.0_07 DerbyNetClient derbynetmats:derbynetmats 
> 2006
> Appears to be related to reported JVM issue: Bug ID:   4665037
>   Synopsis InetAddress.getLocalHost() ambiguous on Linux systems
> see: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4665037

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1330) Provide runtime privilege checking for grant/revoke functionality

[Mamta A. Satoor (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1330?page=comments#action_12425162 ] 

Mamta A. Satoor commented on DERBY-1330:


Laura, here are my attempts at your questions. 

derby.connection.requireAuthentication is a pre 10.2 property which enables 
user authentication. This property will require that a user name and password 
is supplied at database connection time. Chances are that in  a multi-user 
environment, Derby would be run with authentication enabled (more info can be 
found in our existing docs in the 
Security->Derby and Security -> Working with user authentication -> Enabling 
user authentication section)

derby.connection.requireAuthentication will ensures that a user with valid user 
name and password will be allowed to connect to Derby. A multi-user
environment might also want to control what actions are allowed by different 
users once they are connected to Derby. This part falls under User 
authorization. More on this can be found under
Security->Derby and Security -> User authorization -> Setting user authorization

Prior to Derby 10.2, you could use derby.database.defaultConnectionMode to 
specify the default access mode to be noAccess, readOnlyAccess and fullAccess. 
There was no support for Grant/Revoke pre 10.2.

With Derby 10.2, we are introducing grant revoke which is another scheme of 
user authorization and it is enabled by the property 
derby.database.sqlAuthorization. When you set this property to true, Derby is 
said to be running in Derby SQL Standard Authorization mode. So, in short, 
property derby.database.sqlAuthorization allows the grant revoke feature. 

There has been some talk about not requiring property property 
derby.database.sqlAuthorization and enabling grant revoke when user attempts to 
use grant/revoke sql statements for the first time. Someone more knowledgable 
about that discussion might want to add their comments here.

So, I hope I have not gotten you confused with all the jargons. Existing 
manuals might be helpful in clearing out confusion on authentication vs 
authorization.

If you have any further questions, feel free to post them,

> Provide runtime privilege checking for grant/revoke functionality
> -
>
> Key: DERBY-1330
> URL: http://issues.apache.org/jira/browse/DERBY-1330
> Project: Derby
>  Issue Type: Sub-task
>  Components: SQL
>Affects Versions: 10.2.0.0
>Reporter: Mamta A. Satoor
> Assigned To: Mamta A. Satoor
> Attachments: AuthorizationModelForDerbySQLStandardAuthorization.html, 
> AuthorizationModelForDerbySQLStandardAuthorizationV2.html, 
> DERBY1330javaDocWarningsDiffV9.txt, DERBY1330javaDocWarningsStatV9.txt, 
> Derby1330MinorCleanupV7diff.txt, Derby1330MinorCleanupV7stat.txt, 
> Derby1330PrivilegeCollectionV2diff.txt, 
> Derby1330PrivilegeCollectionV2stat.txt, 
> Derby1330PrivilegeCollectionV3diff.txt, 
> Derby1330PrivilegeCollectionV3stat.txt, 
> Derby1330setUUIDinDataDictionaryV10diff.txt, 
> Derby1330setUUIDinDataDictionaryV10stat.txt, 
> Derby1330setUUIDinDataDictionaryV8diff.txt, 
> Derby1330setUUIDinDataDictionaryV8stat.txt, 
> Derby1330uuidIndexForPermsSystemTablesV4diff.txt, 
> Derby1330uuidIndexForPermsSystemTablesV4stat.txt, 
> Derby1330uuidIndexForPermsSystemTablesV5diff.txt, 
> Derby1330uuidIndexForPermsSystemTablesV5stat.txt, 
> Derby1330uuidIndexForPermsSystemTablesV6diff.txt, 
> Derby1330uuidIndexForPermsSystemTablesV6stat.txt, 
> Derby1330ViewPrivilegeCollectionV1diff.txt, 
> Derby1330ViewPrivilegeCollectionV1stat.txt
>
>
> Additional work needs to be done for grant/revoke to make sure that only 
> users with required privileges can access various database objects. In order 
> to do that, first we need to collect the privilege requirements for various 
> database objects and store them in SYS.SYSREQUIREDPERM. Once we have this 
> information then when a user tries to access an object, the required 
> SYS.SYSREQUIREDPERM privileges for the object will be checked against the 
> user privileges in SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and 
> SYS.SYSROUTINEPERMS. The database object access will succeed only if the user 
> has the necessary privileges.
> SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS are already 
> populated by Satheesh's work on DERBY-464. But SYS.SYSREQUIREDPERM doesn't 
> have any information in it at this point and hence no runtime privilege 
> checking is getting done at this point.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux

[Narayanan]

Hi,

Thanx a ton for the issues you have highlighted. I am sorry to have 
missed on the earlier chain of emails regarding proposal of single 
system property. I was just proposing the system property as a possible 
solution and I see the arguments against it as valid. My attempt at 
creating a rather crude simulation of the problem that can occur because 
of synchronization is attached to derby-700.


thanx once again,
Narayanan

Mike Matrigali wrote:
I haven't looked at this yet, just wanted to say that when I proposed 
a single system property (vs. one system prop per database), there was

opposition in the community.

Some things to think about:
o can the same database ever have "2" names - ie. if the location is
  /x/y/wombat and one person accesses as system=/x and db=y/wombat
and another system= /x/y and db=wombat.

o what about when a derby instance fails, like a null pointer or some
  othe bug.  Will the system prop be left around?

o how do you handle synchronization of 2 connects at basically the same
  time?

V.Narayanan (JIRA) wrote:

 [ http://issues.apache.org/jira/browse/DERBY-700?page=all ]

V.Narayanan updated DERBY-700:
--

Attachment: DERBY-700.diff
DERBY-700.stat

Hi,

We could solve this problem by setting a System property before 
booting a database and checking for the property during subsequent 
boots. When the database is shutdown we set the property to false. 
For example when we boot a database named mydb then we set the 
property derby.dblock.mydb = true. Now during subsequent boots we 
could check for this system variable and if it is set to true throw 
an exception. During the shutdown of the database we set this 
variable to false. I tried an attempt along this line in the attached 
patch.
I HAVE NOT run the patch with security manager enabled. The sample 
repro attached with this issue passes with this fix.
Pls note that the patch is not for a commit but is just to represent 
what I have in mind as a solution, in the form of code.

thanx
Narayanan


Derby does not prevent dual boot of database from different 
classloaders on Linux
- 



   Key: DERBY-700
   URL: http://issues.apache.org/jira/browse/DERBY-700
   Project: Derby
Issue Type: Bug
Components: Store
  Affects Versions: 10.1.2.1
   Environment: ava -version
java version "1.4.2_08"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03)
Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode)
  Reporter: Kathey Marsden
   Assigned To: V.Narayanan
  Priority: Critical
   Fix For: 10.2.0.0

   Attachments: DERBY-700.diff, DERBY-700.stat, 
DualBootRepro.java, DualBootRepro2.zip



Derby does not prevent dual boot from two different classloaders on 
Linux.
To reproduce run the  program DualBootRepro with no derby jars in 
your classpath. The program assumes derby.jar is in 
10.1.2.1/derby.jar, you can change the location by changing the 
DERBY_LIB_DIR variable.

On Linux the output is:
$java -cp . DualBootRepro
Loading derby from file:10.1.2.1/derby.jar
10.1.2.1/derby.jar
Booted database in loader [EMAIL PROTECTED]
FAIL: Booted database in 2nd loader [EMAIL PROTECTED]
On Windows I get the expected output.
$ java -cp . DualBootRepro
Loading derby from file:10.1.2.1/derby.jar
10.1.2.1/derby.jar
Booted database in loader [EMAIL PROTECTED]
PASS: Expected exception for dualboot:Another instance of Derby may 
have already booted the database D:\marsden\repro\dualboot\mydb.

Re: [jira] Commented: (DERBY-939) NullPointerException at ResultSet.close() time for simple query using UNION and INTERSECT

[Yip Ng]

Thanks David.On 8/1/06, David Van Couvering (JIRA)  wrote:
[ http://issues.apache.org/jira/browse/DERBY-939?page=comments#action_12425143 ]David Van Couvering commented on DERBY-939:
---Ran derbyall on this, it passed with the exception of known diffs.  Committed revision 427899.  Leaving unresolved as it appears this still needs a release note written for it.
> NullPointerException at ResultSet.close() time for simple query using UNION and INTERSECT> ->> Key: DERBY-939
> URL: http://issues.apache.org/jira/browse/DERBY-939> Project: Derby>  Issue Type: Bug>  Components: SQL
>Affects Versions: 10.2.0.0, 10.1.3.0> Environment: Embedded and server modes, with derby.language.logQueryPlan=true>Reporter: A B
> Assigned To: Yip Ng>Priority: Minor> Attachments: derby939trunkdiffpatch1.txt, derby939trunkdiffpatch2.txt, derby939trunkstatpatch1.txt, derby939trunkstatpatch2.txt>
>> If I set "derby.language.logQueryPlan" to true and then attempt to execute the following simple query using UNION and INTERSECT, Derby will return the correct results and then, _after_ returning the results, will throw a NullPointerException.  This error also occurs for 
10.1.> To reproduce:> > java -Dderby.language.logQueryPlan=true org.apache.derby.tools.ij> and then do:> create table t1 (i int);> create table t2 (j int);> create table t3 (a int);
> ij> select i from t1 union (select j from t2 intersect select a from t3);> 1> ---> 0 rows selected> ERROR XJ001: Java exception: ': java.lang.NullPointerException'.> If I add data, the query will return the correct results,  but then throw the NPE.
> insert into t1 values 1, 2, 3, 4, 5;> insert into t2 values 2, 4, 6, 8, 10;> insert into t3 values 2, 3, 4;> ij> select i from t1 union (select j from t2 intersect select a from t3);> 1
> ---> 1> 2> 3> 4> 5> 5 rows selected> ERROR XJ001: Java exception: ': java.lang.NullPointerException'.> The embedded and client stack traces are shown below. Both suggest that the problem occurs during the close of the result set.
> -- Embedded --> java.lang.NullPointerException>   at org.apache.derby.impl.sql.execute.rts.RealUnionResultSetStatistics.getStatementExecutionPlanText(RealUnionResultSetStatistics.java:107)>   at 
org.apache.derby.impl.sql.execute.rts.RealSortStatistics.getStatementExecutionPlanText(RealSortStatistics.java:124)>   at org.apache.derby.impl.sql.execute.rts.RunTimeStatisticsImpl.getStatementExecutionPlanText
(RunTimeStatisticsImpl.java:293)>   at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.finishAndRTS(BasicNoPutResultSetImpl.java:633)>   at org.apache.derby.impl.sql.execute.SortResultSet.finish
(SortResultSet.java:479)>   at org.apache.derby.impl.jdbc.EmbedResultSet.close(EmbedResultSet.java:533)>   at org.apache.derby.tools.JDBCDisplayUtil.indent_DisplayResults(JDBCDisplayUtil.java:272)
>   at org.apache.derby.tools.JDBCDisplayUtil.DisplayResults(JDBCDisplayUtil.java:260)>   at org.apache.derby.impl.tools.ij.utilMain.displayResult(utilMain.java:381)>   at org.apache.derby.impl.tools.ij.utilMain.doCatch
(utilMain.java:434)>   at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310)>   at org.apache.derby.impl.tools.ij.Main.go(Main.java:203)>   at org.apache.derby.impl.tools.ij.Main.mainCore
(Main.java:169)>   at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55)>   at org.apache.derby.tools.ij.main(ij.java:60)> -- Client --> ERROR (no SQLState): actual code point, 4692 does not match expected code point, 9224
> java.sql.SQLException: actual code point, 4692 does not match expected code point, 9224> at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:280)> at org.apache.derby.client.am.ResultSet.close
(ResultSet.java:412)> at org.apache.derby.tools.JDBCDisplayUtil.indent_DisplayResults(JDBCDisplayUtil.java:272)> at org.apache.derby.tools.JDBCDisplayUtil.DisplayResults(JDBCDisplayUtil.java:260)
> at org.apache.derby.impl.tools.ij.utilMain.displayResult(utilMain.java:381)> at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:434)> at org.apache.derby.impl.tools.ij.utilMain.go
(utilMain.java:310)> at org.apache.derby.impl.tools.ij.Main.go(Main.java:203)> at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:169)> at org.apache.derby.impl.tools.ij.Main14.main
(Main14.java:55)> at org.apache.derby.tools.ij.main(ij.java:60)> Caused by: org.apache.derby.client.am.DisconnectException: actual code point, 4692 does not match ex> pected code point, 9224
> at org.apache.derby.client.net.Reply.zThrowSyntaxError(Reply.java:1157)> at org.apache

[jira] Commented: (DERBY-1619) Sysinfo in 10.2 shows multiple entries if the derby jars reside in a directory with spaces in its name

[John H. Embretsen (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1619?page=comments#action_12425178 ] 

John H. Embretsen commented on DERBY-1619:
--

An excellent and simple solution :)

A note for possible cleanup after we stop supporting J2SE 1.3:

Since URLDecoder.decode(String s) is deprecated, it might be a good idea to 
eventually start using URLDecoder.decode(String s, String enc) (added in 1.4) 
instead, with UTF-8 encoding as recommended by the W3C.

> Sysinfo in 10.2  shows multiple entries if the derby jars reside in a 
> directory with spaces in its name
> ---
>
> Key: DERBY-1619
> URL: http://issues.apache.org/jira/browse/DERBY-1619
> Project: Derby
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 10.2.0.0
> Environment: Windows XP, jdk 1.5
>Reporter: Rajesh Kartha
> Assigned To: Andrew McIntyre
> Fix For: 10.2.0.0
>
> Attachments: derby-1619-v1.diff, derby-1619-v2.diff
>
>
> For the Derby jars residing in C:\Documents and Settings\Administrator\TEMP 
> DIR\lib, the sysinfo shows:
> - Derby Information 
> JRE - JDBC: J2SE 5.0 - JDBC 3.0
> [C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\derby.jar] 
> 10.2.0.5 alpha - (426734)
> [C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\derbytools.jar] 
> 10.2.0.5 alpha - (426734)
> [C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\derbynet.jar] 
> 10.2.0.5 alpha - (426734)
> [C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\derbyclient.jar] 
> 10.2.0.5 alpha - (426734)
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\derby.jar] 10.2.0.5 
> alpha - (426734)
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\derbynet.jar] 10.2.0.5 
> alpha - (426734)
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\derbyclient.jar] 
> 10.2.0.5 alpha - (426734)
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\derbytools.jar] 
> 10.2.0.5 alpha - (426734)
> [C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\db2jcc.jar] 2.6 - 
> (90)
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\db2jcc_license_c.jar] 
> 2.6 - (90)
> --
> This is a regression from 10.1 where the same sysinfo shows:
> - Derby Information 
> JRE - JDBC: J2SE 5.0 - JDBC 3.0
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\derby.jar] 10.1.3.2 - 
> (426741)
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\derbynet.jar] 10.1.3.2 
> - (426741)
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\derbyclient.jar] 
> 10.1.3.2 - (426741)
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\derbytools.jar] 
> 10.1.3.2 - (426741)
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\db2jcc.jar] 2.6 - (90)
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\db2jcc_license_c.jar] 
> 2.6 - (90)
> --

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1625) wisconsin test unable to establish connection

[John H. Embretsen (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1625?page=comments#action_12425179 ] 

John H. Embretsen commented on DERBY-1625:
--

I believe this was caused by changes to the IJ implementation in connection 
with DERBY-1609, and that it was fixed with revision 427801:

r427801 | djd | 2006-08-02 01:51:45 +0200 (Wed, 02 Aug 2006) | 3 lines

DERBY-1609 (partial) Fix wisconsin.java test by initializing the 
connections for the utilMain object.
Once wisconsin.java moves to using the new runScript the initConnections 
method will not be required
by this test and can return to being packahe protected.


See also
http://www.nabble.com/Re%3A-svn-commit%3A-r427293---in--db-derby-code-trunk-java-tools-org-apache-derby-impl-tools-ij%3A-Main.java-mtTestCase.java-utilMain.java-utilMain14.java-p5605343.html


> wisconsin test unable to establish connection
> -
>
> Key: DERBY-1625
> URL: http://issues.apache.org/jira/browse/DERBY-1625
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.2.0.0
> Environment: linux jdk1.4
>Reporter: Rick Hillegas
> Fix For: 10.2.0.0
>
>
> The wisconsin test fails to get a connection on linux under jkd1.4

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Regression Test Failure! - Derby 427658 - Sun DBTG

[Ole . Solberg]

[Auto-generated mail]

*Derby* 427658/2006-08-01 19:46:07 CEST
*derbyall*

Failed  TestsOK  Skip  Duration   Platform
---
*Jvm: 1.6*
19730711 0   111.02% SunOS-5.10_i86pc-i386
  Details in  
http://www.multinet.no/~solberg/public/Apache/DerbyJDK16Jvm1.6/Limited/testSummary-427658.html
 
  Attempted failure analysis in
  
http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJDK16Jvm1.6/427658.html
 
*Jvm: 1.5*
5686681 2   103.85% CYGWIN_NT-5.1_i686-unknown
7686679 2   117.36% CYGWIN_NT-5.2_i686-unknown
   NA NA NANA   Linux-2.6.14-1.1644_FC4_i686-i686
4686682 2   109.76% Linux-2.6.9-34.ELsmp_x86_64-x86_64
4686682 2   193.51% SunOS-5.10_i86pc-i386
4686682 2   145.84% SunOS-5.10_sun4u-sparc
5686681 2   109.06% SunOS-5.11_i86pc-i386
4686682 2   117.37% SunOS-5.9_sun4u-sparc
  Details in  
http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-427658.html
 
  Attempted failure analysis in
  
http://www.multinet.no/~solberg/public/Apache/Failures/Derby/427658.html 
*Jvm: 1.4*
5680675 4   100.41% CYGWIN_NT-5.1_i686-unknown
   NA NA NANA   Linux-2.6.14-1.1644_FC4_i686-i686
4680676 4   116.13% Linux-2.6.9-34.ELsmp_x86_64-x86_64
4680676 4   227.10% SunOS-5.10_i86pc-i386
  Details in  
http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-427658.html
 
  Attempted failure analysis in
  
http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJvm1.4/427658.html 

Changes in  
http://www.multinet.no/~solberg/public/Apache/Derby/UpdateInfo/427658.txt 

( All results in http://www.multinet.no/~solberg/public/Apache/index.html ) 

Regression Test Failure! - TinderBox_Derby 427914 - Sun DBTG

[Ole . Solberg]

[Auto-generated mail]

*TinderBox_Derby* 427914/2006-08-02 08:32:59 CEST
*derbyall*

Failed  TestsOK  Skip  Duration   Platform
---
*Jvm: 1.5*
1687686 2   153.45% SunOS-5.10_i86pc-i386
  Details in  
http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-427914.html
 
  Attempted failure analysis in
  
http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/427914.html
 

Changes in  
http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/427914.txt
 

( All results in http://www.multinet.no/~solberg/public/Apache/index.html ) 

[jira] Updated: (DERBY-1614) Test harness overrides heap size settings when starting Network Server

[John H. Embretsen (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1614?page=all ]

John H. Embretsen updated DERBY-1614:
-

Attachment: DERBY-1614_v1.diff

Attatching patch 'DERBY-1614_v1.diff', which fixes the following issues:

   * harness/NetServer.java: Changes harness behaviour so that no heap settings 
for the Network Server are set if either initial or max heap size has already 
been set in the jvmflags argument of the NetServer constructor. Prior to this 
change, the harness would override heap size settings from the command line or 
test property files unless both old heap flags (-ms or -mx) AND "new" heap 
flags (-Xms or -Xmx) had been set. The harness would also treat initial and max 
sizes independently, which caused incompatibilities in some situations (see 
DERBY-1564). 
   * Behavior has *not* changed in scenarios where jvmflags (when passed to 
NetServer) is null or empty, in which case no extra flags are added.

   * testing/README.htm:
  * fixed small bug in jvmflags example (missing '-' in front of first 
flag).
  * changed jvmflags example from using -ms and -mx to using -Xms and -Xmx, 
since the latter flags are documented non-standard jvm options, while the 
former flags are deprecated (at least in Sun's current Java launchers...), and 
we are just lucky that they still work.
  * added comment about possible consequences of setting only initial or 
only max heap size using jvmflags.


svn stat:

M  java/testing/README.htm
M  java/testing/org/apache/derbyTesting/functionTests/harness/NetServer.java

The patch has been tested with individual test runs of lang/wisconsin.java and 
lang/forupdate.java. Derbyall is still running at the time of writing this...

Please review this patch.


Other patch comments:
--

- If only initial or only max heap size is set using the jvmflags harness 
property, no extra flags will be added by NetServer. This reduces the risk of 
incompatibilities between initial and max values, but it is still possible 
(which is also the case with any other Java application). For Sun's HotSpot JVM 
version 1.5, the default initial heap size is 2 MB, and the default max heap 
size is 64 MB [1]. Hence: 
   - if jvmflags specifies a max value that is smaller than 2 MB 
 (or whatever is the default for a particular JVM), without also 
 setting an initial heap size, or
   - if jvmflags specifies an initial value that is larger than the 
 default max heap size for a particular JVM (e.g. 64 MB),
 without also setting a max heap size,
   - the Java launcher will fail with the message like this:

> Error occurred during initialization of VM
> Incompatible initial and maximum heap sizes specified

- Current behavior depends on the JVM behavior described in DERBY-1091. 
Specifically, this means that as long as all test JVMs use the _last_ value of 
each heap setting if multiple values are specified, and old and new versions of 
heap flags are treated equally, we are all good.

- I was tempted to remove the following line in NetServer.java (but didn't):

 jvm.setNoasyncgc(true); // -noasyncgc

  since no JVM that I know of supports the -noasyncgc option anymore. The last 
HotSpot VM where that option was supported was supposedly version 1.1 [2]. 
Besides, I do not see any reason why we would want to turn of dynamic garbage 
collection for the server when running tests. Anyway, I'll let it be, since 
most jdk* classes in the harness ignore the setting anyway.


[1] http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html and
  http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/java.html

[2] http://forums.java.net/jive/thread.jspa?threadID=16315&tstart=0


> Test harness overrides heap size settings when starting Network Server
> --
>
> Key: DERBY-1614
> URL: http://issues.apache.org/jira/browse/DERBY-1614
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.2.0.0
> Environment: Test frameworks DerbyNet and DerbyNetClient
>Reporter: John H. Embretsen
> Assigned To: John H. Embretsen
> Fix For: 10.2.0.0
>
> Attachments: DERBY-1614_v1.diff
>
>
> Test specific heap size settings can be passed to the test harness using the 
> jvmflags system property, for example in a _app.properties file or 
> at the command line when starting a test, e.g "-Djvmflags=-Xms32m^-Xmx32m".
> The test harness almost always overrides such settings when starting a new 
> Network Server using the 
> org.apache.derbyTesting.functionTests.harness.NetServer class of the test 
> harness. Currently, if _either_ -ms _or_ -Xms is missing from the jvmflags, 
> NetServer.start() adds -ms16777216. Also, if _either_ -mx _or_ -Xmx is 
> missing from the jvmflags, NetServer.start() adds -ms33554432. This has 

[jira] Updated: (DERBY-1614) Test harness overrides heap size settings when starting Network Server

[John H. Embretsen (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1614?page=all ]

John H. Embretsen updated DERBY-1614:
-

Derby Info: [Patch Available]

> Test harness overrides heap size settings when starting Network Server
> --
>
> Key: DERBY-1614
> URL: http://issues.apache.org/jira/browse/DERBY-1614
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.2.0.0
> Environment: Test frameworks DerbyNet and DerbyNetClient
>Reporter: John H. Embretsen
> Assigned To: John H. Embretsen
> Fix For: 10.2.0.0
>
> Attachments: DERBY-1614_v1.diff
>
>
> Test specific heap size settings can be passed to the test harness using the 
> jvmflags system property, for example in a _app.properties file or 
> at the command line when starting a test, e.g "-Djvmflags=-Xms32m^-Xmx32m".
> The test harness almost always overrides such settings when starting a new 
> Network Server using the 
> org.apache.derbyTesting.functionTests.harness.NetServer class of the test 
> harness. Currently, if _either_ -ms _or_ -Xms is missing from the jvmflags, 
> NetServer.start() adds -ms16777216. Also, if _either_ -mx _or_ -Xmx is 
> missing from the jvmflags, NetServer.start() adds -ms33554432. This has been 
> the case since SVN revision 420048 (July 8, 2006).
> Earlier revisions did not override the heap settings unless the newer -Xms or 
> -Xmx flags were used instead of the -ms and -mx flags. A patch for DERBY-1091 
> attempted (among other things) to make the harness recognize the newer flags 
> as well as the older flags, but the resulting behavior is (most likely) not 
> as intended. 
> If a test is run in either the DerbyNet framework or the DerbyNetClient 
> framework, the test-specific JVM flags should (probably) be used for the 
> Network Server JVM as well as the test JVM. Currently, even if non-default 
> heap size flags are passed to the harness, the server JVM will ignore these 
> settings since the harness adds -ms and/or -mx flags _after_ all other heap 
> flags. The exception is if both new and old versions of heap flags are passed 
> to the harness, e.g:
> jvmflags=-ms32m^-Xms32m^-mx128m^-Xmx128m
> Here is the code causing this behaviour:
> if (setJvmFlags && ((jvmflags.indexOf("-ms") == -1) || 
> (jvmflags.indexOf("-Xms") == -1)))
>  // only setMs if no starting memory was given
>  jvm.setMs(16*1024*1024); // -ms16m
> if (setJvmFlags && ((jvmflags.indexOf("-mx") == -1) || 
> (jvmflags.indexOf("-Xmx") == -1)))
>  // only setMx if no max memory was given
>  jvm.setMx(32*1024*1024); // -mx32m

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1614) Test harness overrides heap size settings when starting Network Server

[John H. Embretsen (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1614?page=comments#action_12425214 ] 

John H. Embretsen commented on DERBY-1614:
--

Here is an illustration of how the NetServer class handles heap size settings 
when 'DERBY-1614_v1.diff' is applied:

Input = the value of jvmflags when passed to NetServer
Output = heap flags set when starting the Network Server via NetServer
Old = 10.1.* and trunk SVN 420047 and earlier
Current = current trunk, i.e. SVN 420048 and later
New = current trunk if the above mentioned patch is applied


Input:-ms11m -mx12m
Old output:   -ms11m -mx12m
Current output:   -ms11m -mx12m -ms16777216 -mx33554432
New output:   -ms11m -mx12m

Input:-Xms11m -Xmx12m
Old output:   -Xms11m -Xmx12m -ms16777216 -mx33554432
Current output:   -Xms11m -Xmx12m -ms16777216 -mx33554432
New output:   -Xms11m -Xmx12m

Input:-ms11m
Old output:   -ms11m -mx33554432
Current output:   -ms11m -ms16777216 -mx33554432
New output:   -ms11m

Input:-mx12m
Old output:   -mx12m -ms16777216
Current output:   -mx12m -ms16777216 -mx33554432
New output:   -mx12m

Input:-Xms11m
Old output:   -Xms11m -ms16777216 -mx33554432
Current output:   -Xms11m -ms16777216 -mx33554432
New output:   -Xms11m

Input:-Xmx12m
Old output:   -Xmx12m -ms16777216 -mx33554432
Current output:   -Xmx12m -ms16777216 -mx33554432
New output:   -Xmx12m

Input:-ms11m -Xms12m -mx11m -Xmx12m
Old output:   -ms11m -Xms12m -mx11m -Xmx12m
Current output:   -ms11m -Xms12m -mx11m -Xmx12m
New output:   -ms11m -Xms12m -mx11m -Xmx12m

Input:null or ""
Old output:   
Current output:   
New output:   



> Test harness overrides heap size settings when starting Network Server
> --
>
> Key: DERBY-1614
> URL: http://issues.apache.org/jira/browse/DERBY-1614
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.2.0.0
> Environment: Test frameworks DerbyNet and DerbyNetClient
>Reporter: John H. Embretsen
> Assigned To: John H. Embretsen
> Fix For: 10.2.0.0
>
> Attachments: DERBY-1614_v1.diff
>
>
> Test specific heap size settings can be passed to the test harness using the 
> jvmflags system property, for example in a _app.properties file or 
> at the command line when starting a test, e.g "-Djvmflags=-Xms32m^-Xmx32m".
> The test harness almost always overrides such settings when starting a new 
> Network Server using the 
> org.apache.derbyTesting.functionTests.harness.NetServer class of the test 
> harness. Currently, if _either_ -ms _or_ -Xms is missing from the jvmflags, 
> NetServer.start() adds -ms16777216. Also, if _either_ -mx _or_ -Xmx is 
> missing from the jvmflags, NetServer.start() adds -ms33554432. This has been 
> the case since SVN revision 420048 (July 8, 2006).
> Earlier revisions did not override the heap settings unless the newer -Xms or 
> -Xmx flags were used instead of the -ms and -mx flags. A patch for DERBY-1091 
> attempted (among other things) to make the harness recognize the newer flags 
> as well as the older flags, but the resulting behavior is (most likely) not 
> as intended. 
> If a test is run in either the DerbyNet framework or the DerbyNetClient 
> framework, the test-specific JVM flags should (probably) be used for the 
> Network Server JVM as well as the test JVM. Currently, even if non-default 
> heap size flags are passed to the harness, the server JVM will ignore these 
> settings since the harness adds -ms and/or -mx flags _after_ all other heap 
> flags. The exception is if both new and old versions of heap flags are passed 
> to the harness, e.g:
> jvmflags=-ms32m^-Xms32m^-mx128m^-Xmx128m
> Here is the code causing this behaviour:
> if (setJvmFlags && ((jvmflags.indexOf("-ms") == -1) || 
> (jvmflags.indexOf("-Xms") == -1)))
>  // only setMs if no starting memory was given
>  jvm.setMs(16*1024*1024); // -ms16m
> if (setJvmFlags && ((jvmflags.indexOf("-mx") == -1) || 
> (jvmflags.indexOf("-Xmx") == -1)))
>  // only setMx if no max memory was given
>  jvm.setMx(32*1024*1024); // -mx32m

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1417) Add new, lengthless overloads to the streaming api

[Rick Hillegas (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1417?page=comments#action_12425219 ] 

Rick Hillegas commented on DERBY-1417:
--

Thanks for the explanation, Kristian. Committed at subversion revision 427969.

> Add new, lengthless overloads to the streaming api
> --
>
> Key: DERBY-1417
> URL: http://issues.apache.org/jira/browse/DERBY-1417
> Project: Derby
>  Issue Type: New Feature
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Rick Hillegas
> Assigned To: Kristian Waagan
> Fix For: 10.2.0.0
>
> Attachments: derby-1417-01-castsInTests.diff, 
> derby-1417-1a-notImplemented.diff, derby-1417-1a-notImplemented.stat, 
> derby-1417-2a-rstest-refactor.diff, derby-1417-3a-embimpl-and-tests.diff, 
> derby-1417-3a-embimpl-and-tests.stat, derby-1417-3b-embimpl-and-tests.diff, 
> derby-1417-3b-embimpl-and-tests.stat, derby-1417-4a-disable-psTestsDnc.diff, 
> derby-1417-5a-brokered.diff, derby-1417-5a-brokered.stat, 
> derby-1417-6a-clientimpl.diff, derby-1417-6a-clientimpl.stat, 
> derby-1417-6b-clientimpl.diff, derby-1417-6c-clientimpl.diff, 
> derby-1417-6d-clientimpl.diff, derby-1417-7a-clientborderfix.diff, 
> derby-1417-7a-clientborderfix.stat
>
>
> The JDBC4 Expert Group has approved a new set of overloads for the streaming 
> methods. These overloads do not take a length argument. Here are the new 
> overloads:
> PreparedStatement.setAsciiStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setNCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setBlob(int parameterIndex, java.io.InputStream inputStream)
> PreparedStatement.setClob(int parameterIndex, java.io.Reader reader)
> PreparedStatement.setNClob(int parameterIndex, java.io.Reader reader)
> CallableStatement.setAsciiStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setBinaryStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setNCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setBlob(java.lang.String parameterName, java.io.InputStream 
> inputStream)
> CallableStatement.setClob(java.lang.String parameterName, java.io.Reader 
> reader)
> CallableStatement.setNClob(java.lang.String parameterName, java.io.Reader 
> reader)
> ResultSet.updateAsciiStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateAsciiStream(java.lang.String columnLabel, java.io.InputStream 
> x)
> ResultSet.updateBinaryStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateBinaryStream(java.lang.String columnLabel, 
> java.io.InputStream x, int length)
> ResultSet.updateCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateCharacterStream(java.lang.String columnLabel, java.io.Reader 
> x)
> ResultSet.updateNCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateNCharacterStream(java.lang.String columnLabel, java.io.Reader 
> x)  
> ResultSet.updateBlob(int columnIndex, java.io.InputStream inputStream)
> ResultSet.updateBlob(java.lang.String columnLabel, java.io.InputStream 
> inputStream)
> ResultSet.updateClob(int columnIndex, java.io.Reader reader)
> ResultSet.updateClob(java.lang.String columnLabel, java.io.Reader reader)
> ResultSet.updateNClob(int columnIndex, java.io.Reader reader)
> ResultSet.updateNClob(java.lang.String columnLabel, java.io.Reader reader)
> We should add these new overloads soon so that the build will not break when 
> this methods turn up in a published Mustang build.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1629) StandardException.unexpectedUserException() does not correctly catch internally generated exceptions as of JDK 1.6

[Rick Hillegas (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1629?page=all ]

Rick Hillegas updated DERBY-1629:
-

  Urgency: Normal
Fix Version/s: 10.2.0.0

> StandardException.unexpectedUserException() does not correctly catch 
> internally generated exceptions as of JDK 1.6
> --
>
> Key: DERBY-1629
> URL: http://issues.apache.org/jira/browse/DERBY-1629
> Project: Derby
>  Issue Type: Bug
>Reporter: David Van Couvering
> Fix For: 10.2.0.0
>
>
> In non-JDK 1.6 builds, the exceptions Derby throws are all of class 
> EmbedSQLException.  As of JDK 1.6, that is no longer true.  Instead we throw 
> a "native" SQL Exception.
> That makes the following code incorrect:
>   public static StandardException unexpectedUserException(Throwable t)
>   {
>   /*
>   ** If we have a SQLException that isn't a Util
>   ** (i.e. it didn't come from cloudscape), then we check
>   ** to see if it is a valid user defined exception range 
>   ** (38001-38XXX).  If so, then we convert it into a 
>   ** StandardException without further ado.
>   */ 
>   if ((t instanceof SQLException) &&
>   !(t instanceof EmbedSQLException)) 
>   {
>   SQLException sqlex  = (SQLException)t;
>   String state = sqlex.getSQLState();
>   if ((state != null) && 
>   (state.length() == 5) &&
>   state.startsWith("38") &&
>   !state.equals("38000"))
>   {
>   StandardException se = new 
> StandardException(state, sqlex.getMessage());
>   if (sqlex.getNextException() != null)   
>   {   
>   
> se.setNestedException(sqlex.getNextException());
>   }
>   return se;
>   }
>   }
> I am not sure how we can detect internally-thrown SQL Exceptions and 
> distinguish them from user exceptions, but this does need to be looked at.
> Right now procedureInTrigger.sql is failing for JDK 1.6 due to this error.  I 
> may check in a jdk16-specific version of this file so at least derbyall can 
> pass.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1610) Engine take it as type compatibility error to update column typed as CHAR to value passed via setBinaryStream(null), though Network Client and Network Server does not ta

[Tomohito Nakayama (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1610?page=comments#action_12425235 ] 

Tomohito Nakayama commented on DERBY-1610:
--

Reading the code, it seems that NetworkServer recognize the type of the 
parameter, according to the SQL and not according to the method which passes 
the parameter value.

SQL to be executed in the TestNullChar.java is as next and type of the 
parameter is recognized as CHAR.
INSERT INTO NULL_CHAR_TEST(CHAR_VALUE) VALUES(?)

Ground of my reading is that type data is retrieved from Statement and not from 
FDODSC of SQLDTA.

> Engine take it as type compatibility error to update column typed as CHAR to 
> value passed via setBinaryStream(null), though Network Client and Network 
> Server does not take it as error.
> 
>
> Key: DERBY-1610
> URL: http://issues.apache.org/jira/browse/DERBY-1610
> Project: Derby
>  Issue Type: Bug
>  Components: Network Server, Network Client
>Reporter: Tomohito Nakayama
> Assigned To: Tomohito Nakayama
> Attachments: TestNullChar.java
>
>
> There exists difference between Engine and Network Client/Engine around type 
> compatibility judgement in character typed column when null value was passed 
> as InputStream.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (DERBY-1625) wisconsin test unable to establish connection

[Daniel John Debrunner (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1625?page=all ]

Daniel John Debrunner resolved DERBY-1625.
--

Resolution: Fixed
  Assignee: Daniel John Debrunner

Fixed by commit #427801 under DERBY-1609

> wisconsin test unable to establish connection
> -
>
> Key: DERBY-1625
> URL: http://issues.apache.org/jira/browse/DERBY-1625
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.2.0.0
> Environment: linux jdk1.4
>Reporter: Rick Hillegas
> Assigned To: Daniel John Debrunner
> Fix For: 10.2.0.0
>
>
> The wisconsin test fails to get a connection on linux under jkd1.4

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1579) Remove SYS.SYSREQUIREDPERM from Derby 10.2. This was added for Grant Revoke functionality

[Deepa Remesh (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1579?page=comments#action_12425246 ] 

Deepa Remesh commented on DERBY-1579:
-

I ran derbyall using Sun jdk 1.4.2 on Windows XP with the updated patch 
'derby1579trunkdiff02.txt'. I am seeing one diff in jdbcapi/XATest.java in 
derbynetclientmats framework:

*** Start: XATest jdk1.4.2_06 DerbyNetClient 
derbynetclientmats:derbynetclientmats 2006-08-01 20:04:26 ***
52a53
> (1 |PREPARED |false |APP |UserTransaction   
54d54
< (1 |PREPARED |false |APP |UserTransaction   
Test Failed.
*** End:   XATest jdk1.4.2_06 DerbyNetClient 
derbynetclientmats:derbynetclientmats 2006-08-01 20:04:48 ***

The diff looks like an ordering issue and I don't see how it could be related 
to this patch. However, I am seeing the diff only with this patch and not 
seeing it in a fresh codeline. It would be good if someone else can run this 
test with the patch to confirm this. Thanks.




> Remove SYS.SYSREQUIREDPERM from Derby 10.2. This was added for Grant Revoke 
> functionality
> -
>
> Key: DERBY-1579
> URL: http://issues.apache.org/jira/browse/DERBY-1579
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 10.2.0.0
>Reporter: Mamta A. Satoor
> Assigned To: Yip Ng
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: derby1579trunkdiff01.txt, derby1579trunkdiff02.txt, 
> derby1579trunkstat01.txt, derby1579trunkstat02.txt
>
>
> With the Grant Revoke functionality. Derby engine needs to keep track of 
> view/constraint/trigger's dependencies on various privileges. 
> SYS.SYSREQUIREDPERM table was added for this purpose. But these depdencies 
> can be mantained using the existing Dependency Manager. I have done quite a 
> bit of work using Dependency Manager for Grant Revoke and do not see a need 
> for SYS.SYSREQUIREDPERM. Before 10.2 release, we should drop 
> SYS.SYSREQUIREDPERM from the Derby code and update the Grant/Revoke 
> functional spec accordingly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

How to take connection from derby using DataSource class

[Sube Singh]

Can any one help me how to take connection from Derby using datasource class 
instead of  using JDBC Driver.

[jira] Resolved: (DERBY-1456) Network Server agentError calls log only to console and are hard to diagnose

[Bryan Pendleton (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1456?page=all ]

Bryan Pendleton resolved DERBY-1456.


Fix Version/s: 10.2.0.0
   Resolution: Fixed
   Derby Info:   (was: [Patch Available])

Using the technique suggested by Sunitha in the notes, which involves 
temporarily backing out the fix to DERBY-1454 and then running the repro code 
from that bug, I was able to confirm Sunitha's results and verify that the 
change works for me as well. The exception that is returned to the user is 
vastly more useful, and proper exception information is logged to derby.log.

derbyall run was clean for me as well (modulo strange TransactionTable diff 
which others are also seeing).

Committed the patch to subversion as revision 428012.

Thank you very much for fixing this problem, Sunitha. Can you please close the 
issue at your convenience?


> Network Server agentError calls log only to console and are hard to diagnose
> 
>
> Key: DERBY-1456
> URL: http://issues.apache.org/jira/browse/DERBY-1456
> Project: Derby
>  Issue Type: Sub-task
>  Components: Network Server
>Affects Versions: 10.2.0.0
>Reporter: Bryan Pendleton
> Assigned To: Sunitha Kambhampati
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: 1456_notes.txt, derby1456.diff.txt, derby1456.stat.txt
>
>
> The Network Server code uses an assertion-check utility routine called 
> agentError()
> under certain circumstances. When these agentError() calls arise, for example 
> as
> in DERBY-1454, there is no server side logging of the error except to the 
> console. 
> The user application  that hit DERBY-1454 had not been capturing console 
> output and there 
> was no clue in the derby.log, this made the problem hard to track down when 
> they 
> suddenly hit this boundary deep within their stress tests.
> See also DERBY-743 for another issue with Network Server's agentError routine.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Question around type in DRDA(Re: [jira] Commented: (DERBY-1610) Engine take it as type compatibility error to update column typed as CHAR to value passed via setBinaryStream(null), though Network Clie

[TomohitoNakayama]

Hello.

Concerning DERBY-1610, I'm surveying type definition part in current 
DRDA relating code.


I found there exists two word "DRDA_TYPE" and "FDOCA_TYPE".
Former was found in org.apache.derby.iapi.reference.DRDAConstants and
latter was found in org.apache.derby.client.net.FdocaConstants.

The latter seems to be FTYPE defined in FD:OCA Specifications.
However I'm not sure what former is

Does any one know what is DRDA_TYPE is ?

Best regards.


Tomohito Nakayama (JIRA) wrote:

   [ http://issues.apache.org/jira/browse/DERBY-1610?page=comments#action_12425235 ] 
   
Tomohito Nakayama commented on DERBY-1610:

--

Reading the code, it seems that NetworkServer recognize the type of the 
parameter, according to the SQL and not according to the method which passes 
the parameter value.

SQL to be executed in the TestNullChar.java is as next and type of the 
parameter is recognized as CHAR.
INSERT INTO NULL_CHAR_TEST(CHAR_VALUE) VALUES(?)

Ground of my reading is that type data is retrieved from Statement and not from 
FDODSC of SQLDTA.

 


Engine take it as type compatibility error to update column typed as CHAR to 
value passed via setBinaryStream(null), though Network Client and Network 
Server does not take it as error.


   Key: DERBY-1610
   URL: http://issues.apache.org/jira/browse/DERBY-1610
   Project: Derby
Issue Type: Bug
Components: Network Server, Network Client
  Reporter: Tomohito Nakayama
   Assigned To: Tomohito Nakayama
   Attachments: TestNullChar.java


There exists difference between Engine and Network Client/Engine around type 
compatibility judgement in character typed column when null value was passed as 
InputStream.
   



 



--
/*

   Tomohito Nakayama
   [EMAIL PROTECTED]
   [EMAIL PROTECTED]
   [EMAIL PROTECTED]

   Naka
   http://www5.ocn.ne.jp/~tomohito/TopPage.html

*/ 

Re: Unexplained diff in procedureInTrigger.sql for JDK 1.6

[Mike Matrigali]

Daniel John Debrunner wrote:

David Van Couvering wrote:



Now that I think of it further, I suspect it is not good practice to
hold a test hostage waiting for this bug to be fixed, and I should
probably add a jdk16-specific master file for procedureInTrigger.sql.

I can point the reader of the bug to this master file as a guide to
reproducing the problem...

Any thoughts?  Otherwise I'll go ahead and do that...



Little nervous. Especially as your comment says "so at least derbyall
can pass". With derbyall "passing" a release could go ahead, having
derbyall failing might hold up a release, but I can't see anyone making
DERBY-1629 blocker or critical. Maybe the fact it is marked as a
regression is enough.

Is there any harm in having this test continue fail due to a real bug?


In general I think it is a bad idea to leave "expected" diffs in the
regression suite.  I think it causes unnecessary work for all the
developers trying to figure expected vs. "real" diffs.  I think that
filing a bug and marking it a regression should be enough.

I am not as clear on the right way to "make it pass".  I am 
uncomfortable with just creating new master.   In the past we have

sometimes just removed the test from the suite until the bug is
fixed - which means less testing.  Sometimes we have just removed
the offending statement until the bug is fixed.  And other times
with the canon based tests we have added comments to the test
output itself saying something like "the next few lines are wrong
due to the DERBY-xxx" and then updated that master - that has the
benefit of making it very clear when the bug is fixed and a new
diff appears why it is happening.

is it expected that there is no "time" bomb for junit tests?

[Mike Matrigali]

While running derbyall my run hung all night on a junit test,
I assume this is expected if the test hung.

has anyone seen the jdbcapi/SURTest.junit test hang?

[Mike Matrigali]

A run of derbyall hung for me last night while executing the
jdbcapi/SURTest.junit.  I was running against the latest codeline
with only the patch for DERBY-1456, which bryan ran and passed
for him.  The test passed in this codeline when run standalone -
I only tried it standalone a couple of times but was not able
to reproduce the hang.

/mikem

[jira] Commented: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux

[Rick Hillegas (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-700?page=comments#action_12425259 ] 

Rick Hillegas commented on DERBY-700:
-

Where can Derby store VM-global state? It has been pointed out that System 
properties are an awkward kind of VM-global state for the following reasons:

1) SecurityManager problems
2) Race conditions

What other VM-global state can Derby access? One Derby object that's global 
across the VM is the Derby driver registered with the DriverManager.

1) Could we use the registered Derby driver to anchor VM-global state?
2) Are there other VM-global Derby objects which we could use?


> Derby does not prevent dual boot of database from different classloaders on 
> Linux
> -
>
> Key: DERBY-700
> URL: http://issues.apache.org/jira/browse/DERBY-700
> Project: Derby
>  Issue Type: Bug
>  Components: Store
>Affects Versions: 10.1.2.1
> Environment: ava -version
> java version "1.4.2_08"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode)
>Reporter: Kathey Marsden
> Assigned To: V.Narayanan
>Priority: Critical
> Fix For: 10.2.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, 
> DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.diff, 
> DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.stat, DualBootRepro.java, 
> DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2
>
>
> Derby does not prevent dual boot from two different classloaders on Linux.
> To reproduce run the  program DualBootRepro with no derby jars in your 
> classpath. The program assumes derby.jar is in 10.1.2.1/derby.jar, you can 
> change the location by changing the DERBY_LIB_DIR variable.
> On Linux the output is:
> $java -cp . DualBootRepro
> Loading derby from file:10.1.2.1/derby.jar
> 10.1.2.1/derby.jar
> Booted database in loader [EMAIL PROTECTED]
> FAIL: Booted database in 2nd loader [EMAIL PROTECTED]
> On Windows I get the expected output.
> $ java -cp . DualBootRepro
> Loading derby from file:10.1.2.1/derby.jar
> 10.1.2.1/derby.jar
> Booted database in loader [EMAIL PROTECTED]
> PASS: Expected exception for dualboot:Another instance of Derby may have 
> already booted the database D:\marsden\repro\dualboot\mydb.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Using StorageFactory to create temporary files

[Rick Hillegas]

The patch attached to DERBY-1341 uses the StorageFactory to create a 
temporary file on behalf of the embedded JDBC layer. Is this usage OK? 
Does this violate some assumptions about what server layers are allowed 
to use the StorageFactory?


Would appreciate guidance here. I am out of my depth.

Thanks,
-Rick

[jira] Commented: (DERBY-1630) NetConnection40 references an engine class, org.apache.derby.impl.jdbc.Util

[Rick Hillegas (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1630?page=comments#action_12425267 ] 

Rick Hillegas commented on DERBY-1630:
--

The patch looks good to me. It follows the standard pattern for creating 
SQLExceptions in the network client.

> NetConnection40 references an engine class, org.apache.derby.impl.jdbc.Util
> ---
>
> Key: DERBY-1630
> URL: http://issues.apache.org/jira/browse/DERBY-1630
> Project: Derby
>  Issue Type: Bug
>  Components: Network Client
>Affects Versions: 10.2.0.0
>Reporter: Andrew McIntyre
> Assigned To: Andrew McIntyre
>Priority: Critical
> Fix For: 10.2.0.0
>
> Attachments: derby-1630-v1.diff, derby-1630-v2.diff
>
>
> NetConnection40.java contains this:
> ...
> import org.apache.derby.impl.jdbc.Util;
> ...
>public boolean isValid(int timeout) throws SQLException {
>// Validate that the timeout has a legal value
>if (timeout < 0) {
>throw Util.generateCsSQLException(SQLState.INVALID_API_PARAMETER,
>  new Integer(timeout), "timeout",
>  "java.sql.Connection.isValid");
>}
> ...
> This was added as part of DERBY-1090. This should be changed to use the 
> client's method of throwing exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: is it expected that there is no "time" bomb for junit tests?

[Rick Hillegas]

The following link explains how to set the timeout for an individual 
JUnit test case--however, this mechanism requires jdk1.5 or higher:


http://www.instrumentalservices.com/content/view/45/52/#_Timing_out_a_test

In addition, if you run JUnit tests under ant, you can use the timeout 
attribute of the  task. Do we  have a timeout mechanism for the 
current, home-grown test harness?


Mike Matrigali wrote:


While running derbyall my run hung all night on a junit test,
I assume this is expected if the test hung.

[jira] Commented: (DERBY-1522) Switch(if supported) from Derby Authorization to Derby SQL Standard Authorization needs to be tested

[Deepa Remesh (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1522?page=comments#action_12425269 ] 

Deepa Remesh commented on DERBY-1522:
-

Thanks Mamta for sharing your thoughts on this.

Reading this and the comments in DERBY-1544, I am confused and wondering what 
the planned behaviour for 10.2 is regarding the following:

1) Mamta says: "after the upgrade, all the existing schemas and objects in them 
should be owned by the dba and any other users will need to have permissions 
granted to them by the dba."

Current behaviour is what Mamta says. But DERBY-1544 is open to change the 
behaviour as follows:

"Upgrading a database from 10.1 to 10.2 should automatically change database 
owner, recorded as owner of system schemas in sysschemas, from pseudo user 
'DBA' to authorizationID of the user attempting upgrade."

This is same as what the spec says.  

2) DERBY-1544 mentions adding 5 system routines to routine permission table 
after a full upgrade.

Is DERBY-1544 planned for 10.2 or are we planning to keep the current behaviour?

> Switch(if supported) from Derby Authorization to Derby SQL Standard 
> Authorization needs to be tested
> 
>
> Key: DERBY-1522
> URL: http://issues.apache.org/jira/browse/DERBY-1522
> Project: Derby
>  Issue Type: Task
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Mamta A. Satoor
> Fix For: 10.2.0.0
>
>
> There has been discussions on the Derby-dev list about switch from Derby 
> Authorization to Derby SQL Standard Authorization for existing databases. If 
> we do decide to support a switch like that, testing needs to be done/added to 
> make sure everything works fine after the switch.
> ps I have added this JIRA entry to JDBC component but I am not 100% sure if 
> that is the right component.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: is it expected that there is no "time" bomb for junit tests?

[Kristian Waagan]

Rick Hillegas wrote:
The following link explains how to set the timeout for an individual 
JUnit test case--however, this mechanism requires jdk1.5 or higher:


http://www.instrumentalservices.com/content/view/45/52/#_Timing_out_a_test


I must admit that JUnit4 seems to have several nice features I would 
very much like to use :)


Too bad I must probably wait for years (1.4 EOL) before I can do that 
wrt Derby!




--
Kristian



In addition, if you run JUnit tests under ant, you can use the timeout 
attribute of the  task. Do we  have a timeout mechanism for the 
current, home-grown test harness?


Mike Matrigali wrote:


While running derbyall my run hung all night on a junit test,
I assume this is expected if the test hung.

[jira] Assigned: (DERBY-1473) Add cut-off and truncation logic to streaming classes in the embedded driver

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1473?page=all ]

Kristian Waagan reassigned DERBY-1473:
--

Assignee: Kristian Waagan

> Add cut-off and truncation logic to streaming classes in the embedded driver
> 
>
> Key: DERBY-1473
> URL: http://issues.apache.org/jira/browse/DERBY-1473
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.3.0.0
>Reporter: Kristian Waagan
> Assigned To: Kristian Waagan
>Priority: Minor
>
> When streaming data to Derby, the application stream will be wrapped in a 
> Derby-specific stream to convert the data to the correct representation. At a 
> minimum, this consists of getting the data to the on-disk format used by 
> Derby.
> The wrapping stream can be extended to provide the following features at an 
> earlier stage:
>  a) Data cut-off when the maximum allowed size is exceeded
>  b) Truncation of trailing blanks where allowed
> Both features can reduce the amount of data needed to be kept in memory on 
> insertion.
> Implementing this will require additional column/data type information in the 
> streaming class(es). The implementation must be able to handle streams for 
> which the length is specified and also streams with unknown/unspecified 
> length.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Regression Test Failure! - TinderBox_Derby 427970 - Sun DBTG

[Ole . Solberg]

[Auto-generated mail]

*TinderBox_Derby* 427970/2006-08-02 14:52:43 CEST
*derbyall*

Failed  TestsOK  Skip  Duration   Platform
---
*Jvm: 1.5*
1687686 2   167.52% SunOS-5.10_i86pc-i386
  Details in  
http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-427970.html
 
  Attempted failure analysis in
  
http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/427970.html
 

Changes in  
http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/427970.txt
 

( All results in http://www.multinet.no/~solberg/public/Apache/index.html ) 

Re: [jira] Commented: (DERBY-1330) Provide runtime privilege checking for grant/revoke functionality

[Laura Stewart]

*** (LS) Thank you Mamta.  This is very helpful.  I don't think that
the Derby docs do a good job of describing the difference between user
authentication and user authorization, and I will update the draft
text that I posted for grant/revoke to make it more clear what the
different properties do.
Thanks!
Laura

On 8/2/06, Mamta A. Satoor (JIRA)  wrote:

   [ 
http://issues.apache.org/jira/browse/DERBY-1330?page=comments#action_12425162 ]

Mamta A. Satoor commented on DERBY-1330:


Laura, here are my attempts at your questions.

derby.connection.requireAuthentication is a pre 10.2 property which enables 
user authentication. This property will require that a user name and password 
is supplied at database connection time. Chances are that in  a multi-user 
environment, Derby would be run with authentication enabled (more info can be 
found in our existing docs in the
Security->Derby and Security -> Working with user authentication -> Enabling 
user authentication section)

derby.connection.requireAuthentication will ensures that a user with valid user 
name and password will be allowed to connect to Derby. A multi-user
environment might also want to control what actions are allowed by different 
users once they are connected to Derby. This part falls under User 
authorization. More on this can be found under
Security->Derby and Security -> User authorization -> Setting user authorization

Prior to Derby 10.2, you could use derby.database.defaultConnectionMode to 
specify the default access mode to be noAccess, readOnlyAccess and fullAccess. 
There was no support for Grant/Revoke pre 10.2.

With Derby 10.2, we are introducing grant revoke which is another scheme of 
user authorization and it is enabled by the property 
derby.database.sqlAuthorization. When you set this property to true, Derby is 
said to be running in Derby SQL Standard Authorization mode. So, in short, 
property derby.database.sqlAuthorization allows the grant revoke feature.

There has been some talk about not requiring property property 
derby.database.sqlAuthorization and enabling grant revoke when user attempts to 
use grant/revoke sql statements for the first time. Someone more knowledgable 
about that discussion might want to add their comments here.

So, I hope I have not gotten you confused with all the jargons. Existing 
manuals might be helpful in clearing out confusion on authentication vs 
authorization.

If you have any further questions, feel free to post them,

> Provide runtime privilege checking for grant/revoke functionality
> -
>
> Key: DERBY-1330
> URL: http://issues.apache.org/jira/browse/DERBY-1330
> Project: Derby
>  Issue Type: Sub-task
>  Components: SQL
>Affects Versions: 10.2.0.0
>Reporter: Mamta A. Satoor
> Assigned To: Mamta A. Satoor
> Attachments: AuthorizationModelForDerbySQLStandardAuthorization.html, 
AuthorizationModelForDerbySQLStandardAuthorizationV2.html, 
DERBY1330javaDocWarningsDiffV9.txt, DERBY1330javaDocWarningsStatV9.txt, 
Derby1330MinorCleanupV7diff.txt, Derby1330MinorCleanupV7stat.txt, 
Derby1330PrivilegeCollectionV2diff.txt, Derby1330PrivilegeCollectionV2stat.txt, 
Derby1330PrivilegeCollectionV3diff.txt, Derby1330PrivilegeCollectionV3stat.txt, 
Derby1330setUUIDinDataDictionaryV10diff.txt, 
Derby1330setUUIDinDataDictionaryV10stat.txt, 
Derby1330setUUIDinDataDictionaryV8diff.txt, 
Derby1330setUUIDinDataDictionaryV8stat.txt, 
Derby1330uuidIndexForPermsSystemTablesV4diff.txt, 
Derby1330uuidIndexForPermsSystemTablesV4stat.txt, 
Derby1330uuidIndexForPermsSystemTablesV5diff.txt, 
Derby1330uuidIndexForPermsSystemTablesV5stat.txt, 
Derby1330uuidIndexForPermsSystemTablesV6diff.txt, 
Derby1330uuidIndexForPermsSystemTablesV6stat.txt, 
Derby1330ViewPrivilegeCollectionV1diff.txt, 
Derby1330ViewPrivilegeCollectionV1stat.txt
>
>
> Additional work needs to be done for grant/revoke to make sure that only 
users with required privileges can access various database objects. In order to do 
that, first we need to collect the privilege requirements for various database 
objects and store them in SYS.SYSREQUIREDPERM. Once we have this information then 
when a user tries to access an object, the required SYS.SYSREQUIREDPERM privileges 
for the object will be checked against the user privileges in SYS.SYSTABLEPERMS, 
SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS. The database object access will succeed 
only if the user has the necessary privileges.
> SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS are already 
populated by Satheesh's work on DERBY-464. But SYS.SYSREQUIREDPERM doesn't have 
any information in it at this point and hence no runtime privilege checking is 
getting done at this point.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:

[jira] Commented: (DERBY-1629) StandardException.unexpectedUserException() does not correctly catch internally generated exceptions as of JDK 1.6

[Rick Hillegas (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1629?page=comments#action_12425281 ] 

Rick Hillegas commented on DERBY-1629:
--

Here are various ways to tackle this problem:

1) We could create a parallel universe of SQLException subclasses, which extend 
the JDBC4 SQLException subclasses and implement some vacuous, Derby-specific 
interface. These would be the exceptions raised by SQLExceptionFactory40. 
EmbedSQLException could implement this vacuous interface too. In the code above 
(StandardException.unexpectedUserException()), we could then check whether the 
exception class was an instance of the vacuous interface.

+ I think this covers the cases
- Bloats up the server with around 20 new classes
- As more SQLException subclasses are added to JDBC, we will have to add 
additional parallel Derby classes

2) We could check whether the errorCode was one of the Derby-specific 
severities. This would be our flag that the exception was generated by Derby.

+ Not a lot of code bloat.
- Has wormholes: What if the user-created exception uses one of our severities 
as its error code?

3) We could check whether the passed-in SQLException's getCause() method 
returns an EmbedSQLException. This would be true for all exceptions created by 
SQLExceptionFactory40

+ Also not a lot of code bloat
- Still has the wormhole that the user-created exception could set a Derby 
exception as its cause


> StandardException.unexpectedUserException() does not correctly catch 
> internally generated exceptions as of JDK 1.6
> --
>
> Key: DERBY-1629
> URL: http://issues.apache.org/jira/browse/DERBY-1629
> Project: Derby
>  Issue Type: Bug
>Reporter: David Van Couvering
> Fix For: 10.2.0.0
>
>
> In non-JDK 1.6 builds, the exceptions Derby throws are all of class 
> EmbedSQLException.  As of JDK 1.6, that is no longer true.  Instead we throw 
> a "native" SQL Exception.
> That makes the following code incorrect:
>   public static StandardException unexpectedUserException(Throwable t)
>   {
>   /*
>   ** If we have a SQLException that isn't a Util
>   ** (i.e. it didn't come from cloudscape), then we check
>   ** to see if it is a valid user defined exception range 
>   ** (38001-38XXX).  If so, then we convert it into a 
>   ** StandardException without further ado.
>   */ 
>   if ((t instanceof SQLException) &&
>   !(t instanceof EmbedSQLException)) 
>   {
>   SQLException sqlex  = (SQLException)t;
>   String state = sqlex.getSQLState();
>   if ((state != null) && 
>   (state.length() == 5) &&
>   state.startsWith("38") &&
>   !state.equals("38000"))
>   {
>   StandardException se = new 
> StandardException(state, sqlex.getMessage());
>   if (sqlex.getNextException() != null)   
>   {   
>   
> se.setNestedException(sqlex.getNextException());
>   }
>   return se;
>   }
>   }
> I am not sure how we can detect internally-thrown SQL Exceptions and 
> distinguish them from user exceptions, but this does need to be looked at.
> Right now procedureInTrigger.sql is failing for JDK 1.6 due to this error.  I 
> may check in a jdk16-specific version of this file so at least derbyall can 
> pass.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (DERBY-1616) Lots of jdk1.6 regression test failures with diffs because of SQL Exception instead of java.sql.SQLException

[David Van Couvering (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1616?page=all ]

David Van Couvering resolved DERBY-1616.


Resolution: Fixed

Sending
java/testing/org/apache/derbyTesting/functionTests/harness/Sed.java
Sending
java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/jdk16/ieptests.out
Sending
java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/jdk16/importExport.out
Sending
java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/jdk16/procedure.out
Sending
java/testing/org/apache/derbyTesting/functionTests/master/jdk16/closed.out
Sending
java/testing/org/apache/derbyTesting/functionTests/master/jdk16/releaseCompileLocks.out
Transmitting file data ..
Committed revision 428044.


> Lots of jdk1.6 regression test failures with diffs because of  SQL Exception 
> instead of java.sql.SQLException
> -
>
> Key: DERBY-1616
> URL: http://issues.apache.org/jira/browse/DERBY-1616
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.2.0.0
> Environment: jdk16 /windows.
>Reporter: Sunitha Kambhampati
> Assigned To: David Van Couvering
> Fix For: 10.2.0.0
>
> Attachments: DERBY-1616.diff, derbyall_report.txt
>
>
> jdk16 derbyall derbyall: 19 failures
> derbyall/derbyall.fail:lang/compressTable.sql
> derbyall/derbyall.fail:lang/nestedCommit.sql
> derbyall/derbyall.fail:lang/outparams.java
> derbyall/derbyall.fail:lang/procedure.java
> derbyall/derbyall.fail:lang/procedureInTrigger.sql
> derbyall/derbyall.fail:tools/importExportThruIJ.sql
> derbyall/derbyall.fail:tools/ieptests.sql
> derbyall/derbyall.fail:tools/iepnegativetests.sql
> derbyall/derbyall.fail:jdbcapi/statementJdbc20.java
> derbyall/derbyall.fail:jdbcapi/statementJdbc30.java
> derbyall/derbyall.fail:jdbcapi/parameterMapping.java
> derbyall/derbyall.fail:i18n/iepnegativetests_ES.sql
> 
> derbyall/derbynetclientmats/derbynetclientmats.fail:jdbc4/ClosedObjectTest.junit
> 
> derbyall/derbynetclientmats/derbynetclientmats.fail:jdbc4/UnsupportedVetter.junit
> 
> derbyall/derbynetclientmats/derbynetclientmats.fail:jdbc4/VerifySignatures.junit
> derbyall/encryptionAll/encryption.fail:stress/stress.multi
> derbyall/encryptionAll/storemats.fail:store/streamingColumn.java
> derbyall/storeall/storeall.fail:store/TransactionTable.sql
> derbyall/storeall/storemats.fail:store/streamingColumn.java

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Enforcing length restrictions for streams of unknown length

[Kristian Waagan]

Hello,

My initial work on the new JDBC4 length less overloads are approaching 
completion, but I still have one issue that must be solved.


Currently, streams with unknown length are materialized to determine the 
length. This is the approach I have implemented in the client driver in 
lack of a better solution at the moment. But, the approach is also used 
in the embedded driver, and this is simply not good enough.


If I pass the stream down to the storage layer, bypassing the length 
checks done by the data type classes (SQLBinary, SQLBlob etc), the 
storage layer will insert all the data it can get. For instance, I can 
insert 3KB into a 2KB Blob column.
To solve this, I plan to wrap the user/application stream in a 
limit-stream. This stream will cause an exception to be thrown if it has 
read more data than can be allowed in the column it is being inserted into.


In addition to the maximum length issue, there is also that of 
truncation of trailing blanks. I don't yet fully understand what I have 
to change. Much of the functionality I need is already in place, but 
some changes might be required. For instance, the column width and 
whether truncation is allowed or not might need to be passed down to the 
limit-mechanism.


Questions, suggestions or other feedback is appreciated!



Related issues are DERBY-1473 and DERBY-1417.
I plan to finish this for 10.2.



Thanks,
--
Kristian

[jira] Commented: (DERBY-1522) Switch(if supported) from Derby Authorization to Derby SQL Standard Authorization needs to be tested

[Mamta A. Satoor (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1522?page=comments#action_12425289 ] 

Mamta A. Satoor commented on DERBY-1522:


Deepa, to be more precise, in my statement
"after the upgrade, all the existing schemas and objects in them should be 
owned by the dba and any other users will need to have permissions granted to 
them by the dba." , the *dba* is the user who is attempting the upgrade. So, 
the correct behavior should be what DERBY-1544 is proposing to do.

I think DERBY-1544 should go into 10.2 but I am not sure if anyone is looking 
into it.

> Switch(if supported) from Derby Authorization to Derby SQL Standard 
> Authorization needs to be tested
> 
>
> Key: DERBY-1522
> URL: http://issues.apache.org/jira/browse/DERBY-1522
> Project: Derby
>  Issue Type: Task
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Mamta A. Satoor
> Fix For: 10.2.0.0
>
>
> There has been discussions on the Derby-dev list about switch from Derby 
> Authorization to Derby SQL Standard Authorization for existing databases. If 
> we do decide to support a switch like that, testing needs to be done/added to 
> make sure everything works fine after the switch.
> ps I have added this JIRA entry to JDBC component but I am not 100% sure if 
> that is the right component.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (DERBY-1456) Network Server agentError calls log only to console and are hard to diagnose

[Sunitha Kambhampati (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1456?page=all ]

Sunitha Kambhampati closed DERBY-1456.
--


Thanks very much Bryan for the review and commit of this fix.  I ran some tests 
and have verified it as complete. So closing this issue. 

> Network Server agentError calls log only to console and are hard to diagnose
> 
>
> Key: DERBY-1456
> URL: http://issues.apache.org/jira/browse/DERBY-1456
> Project: Derby
>  Issue Type: Sub-task
>  Components: Network Server
>Affects Versions: 10.2.0.0
>Reporter: Bryan Pendleton
> Assigned To: Sunitha Kambhampati
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: 1456_notes.txt, derby1456.diff.txt, derby1456.stat.txt
>
>
> The Network Server code uses an assertion-check utility routine called 
> agentError()
> under certain circumstances. When these agentError() calls arise, for example 
> as
> in DERBY-1454, there is no server side logging of the error except to the 
> console. 
> The user application  that hit DERBY-1454 had not been capturing console 
> output and there 
> was no clue in the derby.log, this made the problem hard to track down when 
> they 
> suddenly hit this boundary deep within their stress tests.
> See also DERBY-743 for another issue with Network Server's agentError routine.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1522) Switch(if supported) from Derby Authorization to Derby SQL Standard Authorization needs to be tested

[Deepa Remesh (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1522?page=comments#action_12425295 ] 

Deepa Remesh commented on DERBY-1522:
-

Thanks for the clarification, Mamta. I'll take a look at DERBY-1544. 

> Switch(if supported) from Derby Authorization to Derby SQL Standard 
> Authorization needs to be tested
> 
>
> Key: DERBY-1522
> URL: http://issues.apache.org/jira/browse/DERBY-1522
> Project: Derby
>  Issue Type: Task
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Mamta A. Satoor
> Fix For: 10.2.0.0
>
>
> There has been discussions on the Derby-dev list about switch from Derby 
> Authorization to Derby SQL Standard Authorization for existing databases. If 
> we do decide to support a switch like that, testing needs to be done/added to 
> make sure everything works fine after the switch.
> ps I have added this JIRA entry to JDBC component but I am not 100% sure if 
> that is the right component.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1473) Add cut-off and truncation logic to streaming classes in the embedded driver

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1473?page=all ]

Kristian Waagan updated DERBY-1473:
---

  Urgency: Normal
Fix Version/s: 10.2.0.0
Affects Version/s: 10.2.0.0
   (was: 10.3.0.0)
 Priority: Major  (was: Minor)

Updated affect version, fix version, priority and urgency.
I set priority to major, because without this issue fixed, the length less 
overloads can only handle streams that can fit in memory.
I set urgency to normal. Personally, I would have set it to urgent, but I don't 
know if the community feel that way.

I will work to complete this task for 10.2.

> Add cut-off and truncation logic to streaming classes in the embedded driver
> 
>
> Key: DERBY-1473
> URL: http://issues.apache.org/jira/browse/DERBY-1473
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Kristian Waagan
> Assigned To: Kristian Waagan
> Fix For: 10.2.0.0
>
>
> When streaming data to Derby, the application stream will be wrapped in a 
> Derby-specific stream to convert the data to the correct representation. At a 
> minimum, this consists of getting the data to the on-disk format used by 
> Derby.
> The wrapping stream can be extended to provide the following features at an 
> earlier stage:
>  a) Data cut-off when the maximum allowed size is exceeded
>  b) Truncation of trailing blanks where allowed
> Both features can reduce the amount of data needed to be kept in memory on 
> insertion.
> Implementing this will require additional column/data type information in the 
> streaming class(es). The implementation must be able to handle streams for 
> which the length is specified and also streams with unknown/unspecified 
> length.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Assigned: (DERBY-1544) Address remaining upgrade task(s) to complete full upgrade mechanism for GRANT/REVOKE, specifically with changing database owner name from 'DBA' to authorizationId of use

[Deepa Remesh (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1544?page=all ]

Deepa Remesh reassigned DERBY-1544:
---

Assignee: Deepa Remesh

> Address remaining upgrade task(s) to complete full upgrade mechanism for 
> GRANT/REVOKE, specifically with changing database owner name from 'DBA' to 
> authorizationId of user invoking upgrade.
> -
>
> Key: DERBY-1544
> URL: http://issues.apache.org/jira/browse/DERBY-1544
> Project: Derby
>  Issue Type: Sub-task
>  Components: SQL
>Affects Versions: 10.2.0.0
> Environment: generic
>Reporter: Satheesh Bandaram
> Assigned To: Deepa Remesh
> Fix For: 10.2.0.0
>
>
> Upgrading a database from 10.1 to 10.2 should automatically change database 
> owner, recorded as owner of system schemas in sysschemas, from pseudo user 
> 'DBA' to authorizationID of the user attempting upgrade. 
> Another upgrade change I am thinking about is to grant execute privilege to 5 
> system routines that by default have execute privilege to public when a new 
> database is created. Five system routines, two compress routines and three 
> statistics related routines are given execute privilege to public when a new 
> 10.2 database is created. This is not done when a 10.1 database is upgraded 
> to 10.2 and probably good to include these privileges during database upgrade.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1629) StandardException.unexpectedUserException() does not correctly catch internally generated exceptions as of JDK 1.6

[David Van Couvering (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1629?page=comments#action_12425296 ] 

David Van Couvering commented on DERBY-1629:


Thanks for your thoughts, Rick.  It seems to me that for (3) if a user set a 
Derby exception as a cause, getCause() would return a SQLException, not an 
EmbeddedSQLException, so I would argue your wormhole can be closed...

But I don't like how it relies on behavior that could be changed at any time, 
and it's overloading the intention of setCause()/getCause().  But unless we go 
for (1) I can't see any way out of piggybacking extra semantics on one of the 
SQLException methods..., and getCause() seems like the best choice.  

I would suggest that whoever fixes this adds a comment to the 
SQLExceptionFactory40 code that indicates that changing the cause will impact 
other code and describe how and why.

David

> StandardException.unexpectedUserException() does not correctly catch 
> internally generated exceptions as of JDK 1.6
> --
>
> Key: DERBY-1629
> URL: http://issues.apache.org/jira/browse/DERBY-1629
> Project: Derby
>  Issue Type: Bug
>Reporter: David Van Couvering
> Fix For: 10.2.0.0
>
>
> In non-JDK 1.6 builds, the exceptions Derby throws are all of class 
> EmbedSQLException.  As of JDK 1.6, that is no longer true.  Instead we throw 
> a "native" SQL Exception.
> That makes the following code incorrect:
>   public static StandardException unexpectedUserException(Throwable t)
>   {
>   /*
>   ** If we have a SQLException that isn't a Util
>   ** (i.e. it didn't come from cloudscape), then we check
>   ** to see if it is a valid user defined exception range 
>   ** (38001-38XXX).  If so, then we convert it into a 
>   ** StandardException without further ado.
>   */ 
>   if ((t instanceof SQLException) &&
>   !(t instanceof EmbedSQLException)) 
>   {
>   SQLException sqlex  = (SQLException)t;
>   String state = sqlex.getSQLState();
>   if ((state != null) && 
>   (state.length() == 5) &&
>   state.startsWith("38") &&
>   !state.equals("38000"))
>   {
>   StandardException se = new 
> StandardException(state, sqlex.getMessage());
>   if (sqlex.getNextException() != null)   
>   {   
>   
> se.setNestedException(sqlex.getNextException());
>   }
>   return se;
>   }
>   }
> I am not sure how we can detect internally-thrown SQL Exceptions and 
> distinguish them from user exceptions, but this does need to be looked at.
> Right now procedureInTrigger.sql is failing for JDK 1.6 due to this error.  I 
> may check in a jdk16-specific version of this file so at least derbyall can 
> pass.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1629) StandardException.unexpectedUserException() does not correctly catch internally generated exceptions as of JDK 1.6

[David Van Couvering (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1629?page=all ]

David Van Couvering updated DERBY-1629:
---

Priority: Minor  (was: Major)

> StandardException.unexpectedUserException() does not correctly catch 
> internally generated exceptions as of JDK 1.6
> --
>
> Key: DERBY-1629
> URL: http://issues.apache.org/jira/browse/DERBY-1629
> Project: Derby
>  Issue Type: Bug
>Reporter: David Van Couvering
>Priority: Minor
> Fix For: 10.2.0.0
>
>
> In non-JDK 1.6 builds, the exceptions Derby throws are all of class 
> EmbedSQLException.  As of JDK 1.6, that is no longer true.  Instead we throw 
> a "native" SQL Exception.
> That makes the following code incorrect:
>   public static StandardException unexpectedUserException(Throwable t)
>   {
>   /*
>   ** If we have a SQLException that isn't a Util
>   ** (i.e. it didn't come from cloudscape), then we check
>   ** to see if it is a valid user defined exception range 
>   ** (38001-38XXX).  If so, then we convert it into a 
>   ** StandardException without further ado.
>   */ 
>   if ((t instanceof SQLException) &&
>   !(t instanceof EmbedSQLException)) 
>   {
>   SQLException sqlex  = (SQLException)t;
>   String state = sqlex.getSQLState();
>   if ((state != null) && 
>   (state.length() == 5) &&
>   state.startsWith("38") &&
>   !state.equals("38000"))
>   {
>   StandardException se = new 
> StandardException(state, sqlex.getMessage());
>   if (sqlex.getNextException() != null)   
>   {   
>   
> se.setNestedException(sqlex.getNextException());
>   }
>   return se;
>   }
>   }
> I am not sure how we can detect internally-thrown SQL Exceptions and 
> distinguish them from user exceptions, but this does need to be looked at.
> Right now procedureInTrigger.sql is failing for JDK 1.6 due to this error.  I 
> may check in a jdk16-specific version of this file so at least derbyall can 
> pass.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Using StorageFactory to create temporary files

[Mike Matrigali]

This is an unexpected usage, this was never designed for that purpose.
It was originally designed as a module only to be used underneath the
store module.  The purpose was to allow alternate implementations of
the underlying filesystem.

I wonder why straight java i/o stream interfaces were not used?  Is
there anything being provided by the StorageFactory that a direct
use of java io does not easily provide?

I think it would be especially a bad idea to use the storage factory
on the client side of network server as it is going to draw in a lot
of other stuff not currently needed by the client jar.

Rick Hillegas wrote:
The patch attached to DERBY-1341 uses the StorageFactory to create a 
temporary file on behalf of the embedded JDBC layer. Is this usage OK? 
Does this violate some assumptions about what server layers are allowed 
to use the StorageFactory?


Would appreciate guidance here. I am out of my depth.

Thanks,
-Rick

[jira] Commented: (DERBY-1619) Sysinfo in 10.2 shows multiple entries if the derby jars reside in a directory with spaces in its name

[Andrew McIntyre (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1619?page=comments#action_12425304 ] 

Andrew McIntyre commented on DERBY-1619:


[JDK13CLEANUP]

> Sysinfo in 10.2  shows multiple entries if the derby jars reside in a 
> directory with spaces in its name
> ---
>
> Key: DERBY-1619
> URL: http://issues.apache.org/jira/browse/DERBY-1619
> Project: Derby
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 10.2.0.0
> Environment: Windows XP, jdk 1.5
>Reporter: Rajesh Kartha
> Assigned To: Andrew McIntyre
> Fix For: 10.2.0.0
>
> Attachments: derby-1619-v1.diff, derby-1619-v2.diff
>
>
> For the Derby jars residing in C:\Documents and Settings\Administrator\TEMP 
> DIR\lib, the sysinfo shows:
> - Derby Information 
> JRE - JDBC: J2SE 5.0 - JDBC 3.0
> [C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\derby.jar] 
> 10.2.0.5 alpha - (426734)
> [C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\derbytools.jar] 
> 10.2.0.5 alpha - (426734)
> [C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\derbynet.jar] 
> 10.2.0.5 alpha - (426734)
> [C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\derbyclient.jar] 
> 10.2.0.5 alpha - (426734)
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\derby.jar] 10.2.0.5 
> alpha - (426734)
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\derbynet.jar] 10.2.0.5 
> alpha - (426734)
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\derbyclient.jar] 
> 10.2.0.5 alpha - (426734)
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\derbytools.jar] 
> 10.2.0.5 alpha - (426734)
> [C:\Documents%20and%20Settings\Administrator\TEMP%20DIR\lib\db2jcc.jar] 2.6 - 
> (90)
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\db2jcc_license_c.jar] 
> 2.6 - (90)
> --
> This is a regression from 10.1 where the same sysinfo shows:
> - Derby Information 
> JRE - JDBC: J2SE 5.0 - JDBC 3.0
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\derby.jar] 10.1.3.2 - 
> (426741)
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\derbynet.jar] 10.1.3.2 
> - (426741)
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\derbyclient.jar] 
> 10.1.3.2 - (426741)
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\derbytools.jar] 
> 10.1.3.2 - (426741)
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\db2jcc.jar] 2.6 - (90)
> [C:\Documents and Settings\Administrator\TEMP DIR\lib\db2jcc_license_c.jar] 
> 2.6 - (90)
> --

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Unexplained diff in procedureInTrigger.sql for JDK 1.6

[David Van Couvering]

Thanks for the tips, Mike.  I think I'd like to go for adjusting the 
output rather than comment out the statement or pull the test, since it 
is specific to JDK 1.6.


David

Mike Matrigali wrote:



Daniel John Debrunner wrote:

David Van Couvering wrote:



Now that I think of it further, I suspect it is not good practice to
hold a test hostage waiting for this bug to be fixed, and I should
probably add a jdk16-specific master file for procedureInTrigger.sql.

I can point the reader of the bug to this master file as a guide to
reproducing the problem...

Any thoughts?  Otherwise I'll go ahead and do that...



Little nervous. Especially as your comment says "so at least derbyall
can pass". With derbyall "passing" a release could go ahead, having
derbyall failing might hold up a release, but I can't see anyone making
DERBY-1629 blocker or critical. Maybe the fact it is marked as a
regression is enough.

Is there any harm in having this test continue fail due to a real bug?


In general I think it is a bad idea to leave "expected" diffs in the
regression suite.  I think it causes unnecessary work for all the
developers trying to figure expected vs. "real" diffs.  I think that
filing a bug and marking it a regression should be enough.

I am not as clear on the right way to "make it pass".  I am 
uncomfortable with just creating new master.   In the past we have

sometimes just removed the test from the suite until the bug is
fixed - which means less testing.  Sometimes we have just removed
the offending statement until the bug is fixed.  And other times
with the canon based tests we have added comments to the test
output itself saying something like "the next few lines are wrong
due to the DERBY-xxx" and then updated that master - that has the
benefit of making it very clear when the bug is fixed and a new
diff appears why it is happening.

Re: How to take connection from derby using DataSource class

[David Van Couvering]

Hi, Sube.  Take a look at 
http://db.apache.org/derby/docs/dev/devguide/cdevresman89722.html


David

Sube Singh wrote:

Can any one help me how to take connection from Derby using datasource class 
instead of  using JDBC Driver.

[jira] Resolved: (DERBY-1630) NetConnection40 references an engine class, org.apache.derby.impl.jdbc.Util

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1630?page=all ]

Andrew McIntyre resolved DERBY-1630.


Resolution: Fixed
Derby Info:   (was: [Patch Available])

Commited to trunk with revision 428065.

> NetConnection40 references an engine class, org.apache.derby.impl.jdbc.Util
> ---
>
> Key: DERBY-1630
> URL: http://issues.apache.org/jira/browse/DERBY-1630
> Project: Derby
>  Issue Type: Bug
>  Components: Network Client
>Affects Versions: 10.2.0.0
>Reporter: Andrew McIntyre
> Assigned To: Andrew McIntyre
>Priority: Critical
> Fix For: 10.2.0.0
>
> Attachments: derby-1630-v1.diff, derby-1630-v2.diff
>
>
> NetConnection40.java contains this:
> ...
> import org.apache.derby.impl.jdbc.Util;
> ...
>public boolean isValid(int timeout) throws SQLException {
>// Validate that the timeout has a legal value
>if (timeout < 0) {
>throw Util.generateCsSQLException(SQLState.INVALID_API_PARAMETER,
>  new Integer(timeout), "timeout",
>  "java.sql.Connection.isValid");
>}
> ...
> This was added as part of DERBY-1090. This should be changed to use the 
> client's method of throwing exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Enforcing length restrictions for streams of unknown length

[Mike Matrigali]

This may or may not work, not sure.  Here is stuff to be aware of.
If you do this approach, the store will go ahead and insert and log data 
into the database.  For it to work correctly you will

have to make sure that the resulting error from the limit at least
aborts the statement which is doing the insert/update.

My guess is that you are going to get some sort of STORE exception
with the limit exception wrapped below it.  I would not be surprised
if the current store exception is more severe than you want it to
be as the current code does not expect this error - you may have
to define a new less severe error in this case.  There may be more
than one exception path.  Make sure to test the case where
the inserted blob exceeds the page size and the case where the
inserted blob is less than the page size.  Off hand I think this
is a new path for store, I can't think of any case where we expect
to get an exception while reading a stream for insert/update.
With user defined types there use to be an exercised codepath if
the user tried to READ more data than existed in the database -
again this path is no longer exercised since those datatypes were
removed.

This means that after your change a lot more data on disk may be
allocated to the file and the log than before your change.  Some of
this space may never be reclaimed if there are no subsequent inserts
or no explicit compresses.  Probably the worst case would be a user
bug where they defined a default 2 gig blob column, and somehow
generated an infinite loop in the feeding stream - this would then
use 2+ gig of log file and grow the table to 2gig and then return
the error.

This is not a new problem, it is similar to how unique key violations
work today.  A row with many indexes will insert the row, and may
update many indexes before hitting the uniqueness problem.  At that
point all the work is aborted.

I do think that when there is a length we should do the checking up
front, rather than pay the abort and possible space reclamation
penalty.  So unfortunately that would mean multiple paths through
the datatype insert/update stream paths.

Kristian Waagan wrote:

Hello,

My initial work on the new JDBC4 length less overloads are approaching 
completion, but I still have one issue that must be solved.


Currently, streams with unknown length are materialized to determine the 
length. This is the approach I have implemented in the client driver in 
lack of a better solution at the moment. But, the approach is also used 
in the embedded driver, and this is simply not good enough.


If I pass the stream down to the storage layer, bypassing the length 
checks done by the data type classes (SQLBinary, SQLBlob etc), the 
storage layer will insert all the data it can get. For instance, I can 
insert 3KB into a 2KB Blob column.
To solve this, I plan to wrap the user/application stream in a 
limit-stream. This stream will cause an exception to be thrown if it has 
read more data than can be allowed in the column it is being inserted into.


In addition to the maximum length issue, there is also that of 
truncation of trailing blanks. I don't yet fully understand what I have 
to change. Much of the functionality I need is already in place, but 
some changes might be required. For instance, the column width and 
whether truncation is allowed or not might need to be passed down to the 
limit-mechanism.


Questions, suggestions or other feedback is appreciated!



Related issues are DERBY-1473 and DERBY-1417.
I plan to finish this for 10.2.



Thanks,

[jira] Closed: (DERBY-1630) NetConnection40 references an engine class, org.apache.derby.impl.jdbc.Util

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1630?page=all ]

Andrew McIntyre closed DERBY-1630.
--


> NetConnection40 references an engine class, org.apache.derby.impl.jdbc.Util
> ---
>
> Key: DERBY-1630
> URL: http://issues.apache.org/jira/browse/DERBY-1630
> Project: Derby
>  Issue Type: Bug
>  Components: Network Client
>Affects Versions: 10.2.0.0
>Reporter: Andrew McIntyre
> Assigned To: Andrew McIntyre
>Priority: Critical
> Fix For: 10.2.0.0
>
> Attachments: derby-1630-v1.diff, derby-1630-v2.diff
>
>
> NetConnection40.java contains this:
> ...
> import org.apache.derby.impl.jdbc.Util;
> ...
>public boolean isValid(int timeout) throws SQLException {
>// Validate that the timeout has a legal value
>if (timeout < 0) {
>throw Util.generateCsSQLException(SQLState.INVALID_API_PARAMETER,
>  new Integer(timeout), "timeout",
>  "java.sql.Connection.isValid");
>}
> ...
> This was added as part of DERBY-1090. This should be changed to use the 
> client's method of throwing exceptions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Enforcing length restrictions for streams of unknown length

[Mike Matrigali]

Mike Matrigali wrote:

This may or may not work, not sure.  Here is stuff to be aware of.
If you do this approach, the store will go ahead and insert and log data 
into the database.  For it to work correctly you will

have to make sure that the resulting error from the limit at least
aborts the statement which is doing the insert/update.

My guess is that you are going to get some sort of STORE exception
with the limit exception wrapped below it.  I would not be surprised
if the current store exception is more severe than you want it to
be as the current code does not expect this error - you may have
to define a new less severe error in this case.  There may be more
than one exception path.  Make sure to test the case where
the inserted blob exceeds the page size and the case where the
inserted blob is less than the page size. 


By severity I meant that store may currently raise a transaction or
system level exception.  A good test would be to have a multi-statement
transaction and make sure this error does not back out an earlier 
statement in the uncommitted transation.

[jira] Commented: (DERBY-1522) Switch(if supported) from Derby Authorization to Derby SQL Standard Authorization needs to be tested

[Satheesh Bandaram (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1522?page=comments#action_12425338 ] 

Satheesh Bandaram commented on DERBY-1522:
--

1) Mamta says: "after the upgrade, all the existing schemas and objects in them 
should be owned by the dba and any other users will need to have permissions 
granted to them by the dba." 

Don't think that is true... Even in Derby authorization mode, schemas created 
by regular users have their authorizationId recorded in sysschemas. Derby 
authorization mode only recognises fullAccessUsers (who can modify any object 
owned by anyone) or readOnlyAccess or no access. But once switching to SQL 
authorization mode, only schema owners would have access to objects in their 
schema and others would need explicit GRANT from schema owner to be able to 
access them.

As far as additional testing for switching from Derby authorization mode to SQL 
mode, tests to cover include new restrictions we currently have on SQL 
authorization mode and to make sure they are actually enforced correctly. Some 
of the items to check, after switching to SQL authorization mode, include 1) 
Only owners can access their objects 2) regular users can only create a schema 
that matches their authorizationId 3) Database owner can access any object in 
the system 4) definer model being correctly enforced etc. 5) Access to many 
system routines are restricted 6) Cann't switch mode back to Derby authorization

Thanks Deepa for looking at DERBY-1544.
 

> Switch(if supported) from Derby Authorization to Derby SQL Standard 
> Authorization needs to be tested
> 
>
> Key: DERBY-1522
> URL: http://issues.apache.org/jira/browse/DERBY-1522
> Project: Derby
>  Issue Type: Task
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Mamta A. Satoor
> Fix For: 10.2.0.0
>
>
> There has been discussions on the Derby-dev list about switch from Derby 
> Authorization to Derby SQL Standard Authorization for existing databases. If 
> we do decide to support a switch like that, testing needs to be done/added to 
> make sure everything works fine after the switch.
> ps I have added this JIRA entry to JDBC component but I am not 100% sure if 
> that is the right component.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (DERBY-1633) Regression: The fields of views are not being calculated properly since 10.1.2.4

[Prasenjit Sarkar (JIRA)]

Regression: The fields of views are not being calculated properly since 10.1.2.4


 Key: DERBY-1633
 URL: http://issues.apache.org/jira/browse/DERBY-1633
 Project: Derby
  Issue Type: Bug
  Components: Regression Test Failure
Affects Versions: 10.1.3.1, 10.1.3.0
 Environment: 2.8 GHZ dual PIV on Windows XP SP2, 2 GB memory
Reporter: Prasenjit Sarkar


Database can be assumed to be same as in Derby - 1205 Jira issue

SELECT PORT1.PORT_ID FROM T_RES_PORT PORT1, T_VIEW_ENTITY2PORT ENTITY2PORT 
WHERE ENTITY2PORT.PORT_ID = PORT1.PORT_ID

This works fine in 10.1.2.1 but fails thereafter complaining that Comparison 
between INTEGER and CHAR is not supported

for some reason, it thinks one of the PORT_ID columns is a character, when in 
reality both are integers.

SELECT DISTINCT 
ZONE.ZONE_ID ZONE_ID, 
 PORT2ZONE.ZONE_MEMBER_ID  
FROM  
 T_RES_ZONE ZONE left outer join T_VIEW_PORT2ZONE 
PORT2ZONE on  
 ZONE.ZONE_ID = PORT2ZONE.ZONE_ID   ,  T_RES_FABRIC 
FABRIC 

In this query, it is complaining that one of the columns is a VARCHAR and 
cannot be compared to INTEGER, when clearly this is not the case...

Same issue

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network

[Craig Russell (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12425340 ] 

Craig Russell commented on DERBY-1516:
--

There is different behavior between embedded and network in other areas as well 
as the one I'm looking at here. I'd like to see what people think about this as 
well. It's hard to add test cases for zero-length requests without 
rationalizing the current behavior.

1. Both embedded and network do not return an error but truncate the result 
when going past the end of the Clob. That is, ask a Clob with length 25 for 50 
characters starting at position 1 and get 26 characters and no exception.

Proposal: Leave this behavior; we would need to add a new message, since the 
current message "SQLSTATE(XJ076): The position argument '5,910' exceeds the 
size of the BLOB/CLOB" cannot be used to describe running off the end of the 
Clob. I'd like to see this changed in future, to match the java.lang.String 
behavior, but this is a compatibility issue (existing applications might depend 
on this behavior).

2. Different behavior for zero-length Clobs:
Embedded Clob with zero length: throws an exception trying to get any non-zero 
length substring
Network Clob with zero length throws an exception only if the position is not 
== 1.

Proposal: Change Network to throw an exception on any request to get a non-zero 
length substring.

Craig

> Inconsistent behavior for getBytes and getSubString for embedded versus 
> network
> ---
>
> Key: DERBY-1516
> URL: http://issues.apache.org/jira/browse/DERBY-1516
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC
>Reporter: Craig Russell
> Assigned To: Craig Russell
>Priority: Minor
> Attachments: DERBY-1516.patch, DERBY-1516.patch, DERBY-1516.patch
>
>
> org.apache.derby.client.am.Clob.getSubString(pos, length) and 
> org.apache.derby.client.am.Blob.getBytes(pos, length) check the length for 
> less than zero. 
> if ((pos <= 0) || (length < 0)) {
> throw new SqlException(agent_.logWriter_, "Invalid position " 
> + pos + " or length " + length);
> But org.apache.derby.impl.jdbc.EmbedClob(pos, length) and 
> org.apache.derby.impl.jdbc.EmbedBlob(pos, length) check the length for less 
> than or equal to zero.
>if (length <= 0)
> throw Util.generateCsSQLException(
> SQLState.BLOB_NONPOSITIVE_LENGTH, new Integer(length));
> The specification does not disallow length of zero, so zero length should be 
> allowed. I believe that the implementation in org.apache.derby.client.am is 
> correct, and the implementation in org.apache.derby.impl.jdbc is incorrect. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Assigned: (DERBY-1633) Regression: The fields of views are not being calculated properly since 10.1.2.4

[A B (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1633?page=all ]

A B reassigned DERBY-1633:
--

Assignee: A B

Looks like an issue with the predicate scoping that occurs as part of predicate 
pushdown for UNIONs--see DERBY-805.  I will look into it...

> Regression: The fields of views are not being calculated properly since 
> 10.1.2.4
> 
>
> Key: DERBY-1633
> URL: http://issues.apache.org/jira/browse/DERBY-1633
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.1.3.0, 10.1.3.1
> Environment: 2.8 GHZ dual PIV on Windows XP SP2, 2 GB memory
>Reporter: Prasenjit Sarkar
> Assigned To: A B
>
> Database can be assumed to be same as in Derby - 1205 Jira issue
> SELECT PORT1.PORT_ID FROM T_RES_PORT PORT1, T_VIEW_ENTITY2PORT ENTITY2PORT 
> WHERE ENTITY2PORT.PORT_ID = PORT1.PORT_ID
> This works fine in 10.1.2.1 but fails thereafter complaining that Comparison 
> between INTEGER and CHAR is not supported
> for some reason, it thinks one of the PORT_ID columns is a character, when in 
> reality both are integers.
>   SELECT DISTINCT 
>   ZONE.ZONE_ID ZONE_ID, 
>PORT2ZONE.ZONE_MEMBER_ID  
>   FROM  
>T_RES_ZONE ZONE left outer join T_VIEW_PORT2ZONE 
> PORT2ZONE on  
>ZONE.ZONE_ID = PORT2ZONE.ZONE_ID   ,  T_RES_FABRIC 
> FABRIC 
> In this query, it is complaining that one of the columns is a VARCHAR and 
> cannot be compared to INTEGER, when clearly this is not the case...
> Same issue

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1633) Regression: The fields of views are not being calculated properly since 10.1.2.4

[A B (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1633?page=all ]

A B updated DERBY-1633:
---

Component/s: SQL
 (was: Regression Test Failure)

> Regression: The fields of views are not being calculated properly since 
> 10.1.2.4
> 
>
> Key: DERBY-1633
> URL: http://issues.apache.org/jira/browse/DERBY-1633
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.1.3.0, 10.1.3.1
> Environment: 2.8 GHZ dual PIV on Windows XP SP2, 2 GB memory
>Reporter: Prasenjit Sarkar
> Assigned To: A B
>
> Database can be assumed to be same as in Derby - 1205 Jira issue
> SELECT PORT1.PORT_ID FROM T_RES_PORT PORT1, T_VIEW_ENTITY2PORT ENTITY2PORT 
> WHERE ENTITY2PORT.PORT_ID = PORT1.PORT_ID
> This works fine in 10.1.2.1 but fails thereafter complaining that Comparison 
> between INTEGER and CHAR is not supported
> for some reason, it thinks one of the PORT_ID columns is a character, when in 
> reality both are integers.
>   SELECT DISTINCT 
>   ZONE.ZONE_ID ZONE_ID, 
>PORT2ZONE.ZONE_MEMBER_ID  
>   FROM  
>T_RES_ZONE ZONE left outer join T_VIEW_PORT2ZONE 
> PORT2ZONE on  
>ZONE.ZONE_ID = PORT2ZONE.ZONE_ID   ,  T_RES_FABRIC 
> FABRIC 
> In this query, it is complaining that one of the columns is a VARCHAR and 
> cannot be compared to INTEGER, when clearly this is not the case...
> Same issue

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1629) StandardException.unexpectedUserException() does not correctly catch internally generated exceptions as of JDK 1.6

[Daniel John Debrunner (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1629?page=comments#action_12425349 ] 

Daniel John Debrunner commented on DERBY-1629:
--

Can the summary of this bug be changed to reflect the impact on/change 
to/incorect behavaiour an application would see. This will be a regression when 
running on jdk 16 for an application, but what exactly is the regression?

> StandardException.unexpectedUserException() does not correctly catch 
> internally generated exceptions as of JDK 1.6
> --
>
> Key: DERBY-1629
> URL: http://issues.apache.org/jira/browse/DERBY-1629
> Project: Derby
>  Issue Type: Bug
>Reporter: David Van Couvering
>Priority: Minor
> Fix For: 10.2.0.0
>
>
> In non-JDK 1.6 builds, the exceptions Derby throws are all of class 
> EmbedSQLException.  As of JDK 1.6, that is no longer true.  Instead we throw 
> a "native" SQL Exception.
> That makes the following code incorrect:
>   public static StandardException unexpectedUserException(Throwable t)
>   {
>   /*
>   ** If we have a SQLException that isn't a Util
>   ** (i.e. it didn't come from cloudscape), then we check
>   ** to see if it is a valid user defined exception range 
>   ** (38001-38XXX).  If so, then we convert it into a 
>   ** StandardException without further ado.
>   */ 
>   if ((t instanceof SQLException) &&
>   !(t instanceof EmbedSQLException)) 
>   {
>   SQLException sqlex  = (SQLException)t;
>   String state = sqlex.getSQLState();
>   if ((state != null) && 
>   (state.length() == 5) &&
>   state.startsWith("38") &&
>   !state.equals("38000"))
>   {
>   StandardException se = new 
> StandardException(state, sqlex.getMessage());
>   if (sqlex.getNextException() != null)   
>   {   
>   
> se.setNestedException(sqlex.getNextException());
>   }
>   return se;
>   }
>   }
> I am not sure how we can detect internally-thrown SQL Exceptions and 
> distinguish them from user exceptions, but this does need to be looked at.
> Right now procedureInTrigger.sql is failing for JDK 1.6 due to this error.  I 
> may check in a jdk16-specific version of this file so at least derbyall can 
> pass.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1629) StandardException.unexpectedUserException() does not correctly catch internally generated exceptions as of JDK 1.6

[Daniel John Debrunner (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1629?page=comments#action_12425354 ] 

Daniel John Debrunner commented on DERBY-1629:
--

I think it's also worth re-validating the requirements, some of the assumptions 
about that method are from the old Cloudscape days when any java method could 
be executed from SQL. Looking again it seems as though the current behaviour 
for routines is wrong and would not require knowing if an exception was thrown 
by Derby or not. Other uses of the method might though. The behaviour for 
routines is defined in SQL part 13, section 15.1, which seems to boil down to:

If a method throws an exception E  then

if (method instance of java.sql.Exception)
{
   if SQL state starts with "38", is at least 5 characters and is not 38000
   throw an exception with E's SQL state
else
   throw an exception with SQL state 39001
}
else
{
   throw an exception with SQL state 38000
}

Assuming we can take the meaning of "class of  E is java.sql.SQLException" to 
mean instanceof and not class has to be java.sql.SQLException,
since this was written before SQLException had sub-classes.


> StandardException.unexpectedUserException() does not correctly catch 
> internally generated exceptions as of JDK 1.6
> --
>
> Key: DERBY-1629
> URL: http://issues.apache.org/jira/browse/DERBY-1629
> Project: Derby
>  Issue Type: Bug
>Reporter: David Van Couvering
>Priority: Minor
> Fix For: 10.2.0.0
>
>
> In non-JDK 1.6 builds, the exceptions Derby throws are all of class 
> EmbedSQLException.  As of JDK 1.6, that is no longer true.  Instead we throw 
> a "native" SQL Exception.
> That makes the following code incorrect:
>   public static StandardException unexpectedUserException(Throwable t)
>   {
>   /*
>   ** If we have a SQLException that isn't a Util
>   ** (i.e. it didn't come from cloudscape), then we check
>   ** to see if it is a valid user defined exception range 
>   ** (38001-38XXX).  If so, then we convert it into a 
>   ** StandardException without further ado.
>   */ 
>   if ((t instanceof SQLException) &&
>   !(t instanceof EmbedSQLException)) 
>   {
>   SQLException sqlex  = (SQLException)t;
>   String state = sqlex.getSQLState();
>   if ((state != null) && 
>   (state.length() == 5) &&
>   state.startsWith("38") &&
>   !state.equals("38000"))
>   {
>   StandardException se = new 
> StandardException(state, sqlex.getMessage());
>   if (sqlex.getNextException() != null)   
>   {   
>   
> se.setNestedException(sqlex.getNextException());
>   }
>   return se;
>   }
>   }
> I am not sure how we can detect internally-thrown SQL Exceptions and 
> distinguish them from user exceptions, but this does need to be looked at.
> Right now procedureInTrigger.sql is failing for JDK 1.6 due to this error.  I 
> may check in a jdk16-specific version of this file so at least derbyall can 
> pass.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

derby-developers group request

[Adams, James F]

Could someone add me to the derby-developers group? (jira user
james.f.adams)

James F. Adams

[jira] Updated: (DERBY-1629) StandardException.unexpectedUserException() does not correctly catch internally generated exceptions as of JDK 1.6

[David Van Couvering (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1629?page=all ]

David Van Couvering updated DERBY-1629:
---

Description: In Java SE 6 runtime environments, an application may not get 
the SQL Exception with SQL State 38000 when execution of a trigger or procedure 
fails with an exception caused by Derby internals.  Instead, they will get the 
underlying exception with it's SQL State.  For an example of this, see 
lang/procedureInTrigger.sql, which has different output for Java SE 6 (encoded 
in the master/jdk16/procedureInTrigger.out file) than for other Java SE 
runtimes.  (was: In non-JDK 1.6 builds, the exceptions Derby throws are all of 
class EmbedSQLException.  As of JDK 1.6, that is no longer true.  Instead we 
throw a "native" SQL Exception.

That makes the following code incorrect:

public static StandardException unexpectedUserException(Throwable t)
{
/*
** If we have a SQLException that isn't a Util
** (i.e. it didn't come from cloudscape), then we check
** to see if it is a valid user defined exception range 
** (38001-38XXX).  If so, then we convert it into a 
** StandardException without further ado.
*/ 
if ((t instanceof SQLException) &&
!(t instanceof EmbedSQLException)) 
{
SQLException sqlex  = (SQLException)t;
String state = sqlex.getSQLState();
if ((state != null) && 
(state.length() == 5) &&
state.startsWith("38") &&
!state.equals("38000"))
{
StandardException se = new 
StandardException(state, sqlex.getMessage());
if (sqlex.getNextException() != null)   
{   

se.setNestedException(sqlex.getNextException());
}
return se;
}
}

I am not sure how we can detect internally-thrown SQL Exceptions and 
distinguish them from user exceptions, but this does need to be looked at.

Right now procedureInTrigger.sql is failing for JDK 1.6 due to this error.  I 
may check in a jdk16-specific version of this file so at least derbyall can 
pass.
)
 Derby Info: [Existing Application Impact, Regression]

Fixed this to describe user-perceived behavior.  Here is the original comment, 
which provides useful implementation details:

In non-JDK 1.6 builds, the exceptions Derby throws are all of class 
EmbedSQLException. As of JDK 1.6, that is no longer true. Instead we throw a 
"native" SQL Exception.

That makes the following code incorrect:

public static StandardException unexpectedUserException(Throwable t)
{
/*
** If we have a SQLException that isn't a Util
** (i.e. it didn't come from cloudscape), then we check
** to see if it is a valid user defined exception range
** (38001-38XXX). If so, then we convert it into a
** StandardException without further ado.
*/
if ((t instanceof SQLException) &&
!(t instanceof EmbedSQLException))
{
SQLException sqlex = (SQLException)t;
String state = sqlex.getSQLState();
if ((state != null) &&
(state.length() == 5) &&
state.startsWith("38") &&
!state.equals("38000"))
{
StandardException se = new StandardException(state, sqlex.getMessage());
if (sqlex.getNextException() != null)
{
se.setNestedException(sqlex.getNextException());
}
return se;
}
}

I am not sure how we can detect internally-thrown SQL Exceptions and 
distinguish them from user exceptions, but this does need to be looked at.

Right now procedureInTrigger.sql is failing for JDK 1.6 due to this error. I 
may check in a jdk16-specific version of this file so at least derbyall can 
pass. 

> StandardException.unexpectedUserException() does not correctly catch 
> internally generated exceptions as of JDK 1.6
> --
>
> Key: DERBY-1629
> URL: http://issues.apache.org/jira/browse/DERBY-1629
> Project: Derby
>  Issue Type: Bug
>Reporter: David Van Couvering
>Priority: Minor
> Fix For: 10.2.0.0
>
>
> In Java SE 6 runtime environments, an application may not get the SQL 
> Exception with SQL State 38000 when execution of a trigger or procedure fails 
> with an exception caused by Derby internals.  Instead, they will get the 
> underlying exception with it's SQL State.  For an example of this, see 
> lang/procedureInTrigger.sql, which has different output for Java SE 6 
> (encoded in the master/jdk16/procedureInTrigger.out file) than for other Java 
> SE runtimes.

-

[jira] Commented: (DERBY-1629) StandardException.unexpectedUserException() does not correctly catch internally generated exceptions as of JDK 1.6

[David Van Couvering (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1629?page=comments#action_12425356 ] 

David Van Couvering commented on DERBY-1629:


I think what you described is in the SQL spec is not what is happening in this 
code right now, and should be fixed.  And I think you're right that this does 
not require us to know whether the exception is a Derby exception or not, who 
knows, the procedure could be calling some other backend database.  That 
simplifies things I think.

> StandardException.unexpectedUserException() does not correctly catch 
> internally generated exceptions as of JDK 1.6
> --
>
> Key: DERBY-1629
> URL: http://issues.apache.org/jira/browse/DERBY-1629
> Project: Derby
>  Issue Type: Bug
>Reporter: David Van Couvering
>Priority: Minor
> Fix For: 10.2.0.0
>
>
> In Java SE 6 runtime environments, an application may not get the SQL 
> Exception with SQL State 38000 when execution of a trigger or procedure fails 
> with an exception caused by Derby internals.  Instead, they will get the 
> underlying exception with it's SQL State.  For an example of this, see 
> lang/procedureInTrigger.sql, which has different output for Java SE 6 
> (encoded in the master/jdk16/procedureInTrigger.out file) than for other Java 
> SE runtimes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: derby-developers group request

[Andrew McIntyre]

On 8/2/06, Adams, James F <[EMAIL PROTECTED]> wrote:

Could someone add me to the derby-developers group? (jira user
james.f.adams)


Hi James,

Are you registered with this email address? If so, I couldn't find
your user in JIRA. If it is registered with a different email address,
please let me know that email address and I can add you to the
derby-developers group.

Thanks,
andrew

[jira] Updated: (DERBY-1544) Address remaining upgrade task(s) to complete full upgrade mechanism for GRANT/REVOKE, specifically with changing database owner name from 'DBA' to authorizationId of user

[Deepa Remesh (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1544?page=all ]

Deepa Remesh updated DERBY-1544:


Attachment: d1544-patch1-draft.diff

Attaching a draft patch 'd1544-patch1-draft.diff' for the first part of this 
sub-task - Upgrading a database from 10.1 to 10.2 should automatically change 
database owner, recorded as owner of system schemas in sysschemas, from pseudo 
user 'DBA' to authorizationID of the user attempting upgrade.

This was being done in DataDictionaryImpl.updateSchemaAuth method. I think a 
wrong index was being used in the call to updateRow. Also the SCHEMAAID column 
which we are changing is not part of any index in SYSSCHEMAS. So there is no 
need to update any index.

With this patch, I tested that after upgrade, the authorization id for the 
system schemas get changed to that of the user invoking upgrade. I have to 
create a regression test and also run more tests with this. Meantime, any 
feedback is appreciated. 

> Address remaining upgrade task(s) to complete full upgrade mechanism for 
> GRANT/REVOKE, specifically with changing database owner name from 'DBA' to 
> authorizationId of user invoking upgrade.
> -
>
> Key: DERBY-1544
> URL: http://issues.apache.org/jira/browse/DERBY-1544
> Project: Derby
>  Issue Type: Sub-task
>  Components: SQL
>Affects Versions: 10.2.0.0
> Environment: generic
>Reporter: Satheesh Bandaram
> Assigned To: Deepa Remesh
> Fix For: 10.2.0.0
>
> Attachments: d1544-patch1-draft.diff
>
>
> Upgrading a database from 10.1 to 10.2 should automatically change database 
> owner, recorded as owner of system schemas in sysschemas, from pseudo user 
> 'DBA' to authorizationID of the user attempting upgrade. 
> Another upgrade change I am thinking about is to grant execute privilege to 5 
> system routines that by default have execute privilege to public when a new 
> database is created. Five system routines, two compress routines and three 
> statistics related routines are given execute privilege to public when a new 
> 10.2 database is created. This is not done when a 10.1 database is upgraded 
> to 10.2 and probably good to include these privileges during database upgrade.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] Commented: (DERBY-1500) PreparedStatement#setObject(int parameterIndex, Object x) throws SQL Exception when binding Short value in embedded mode

[Lance J. Andersen]

I updated the JDBC 4 spec data conversion tables for Short and Byte so
I would add support for  them when u can

-lance

Markus Fuchs (JIRA) wrote:

  [ http://issues.apache.org/jira/browse/DERBY-1500?page=comments#action_12424627 ] 

Markus Fuchs commented on DERBY-1500:
-

This behavior is apparantly implemented by many major database vendors, e.g. Oracle, SQLServer, Sybase, and the Derby network server. Because it's undefined by the JDBC spec doesn't mean that it *must* not be provided for user convenience. 

  
  
PreparedStatement#setObject(int parameterIndex, Object x) throws SQL Exception when binding Short value in embedded mode


Key: DERBY-1500
URL: http://issues.apache.org/jira/browse/DERBY-1500
Project: Derby
 Issue Type: Bug
 Components: JDBC
   Affects Versions: 10.1.1.0, 10.1.3.1
Environment: WindowsXP
   Reporter: Markus Fuchs
Attachments: ShortTest.java


When trying to insert a row into the table 
SHORT_TEST( ID int, SHORT_VAL smallint)
an exception is thrown, if the object value given to PreparedStatement#setObject(int parameterIndex, Object x) is of type Short. The exception thrown is:
--- SQLException ---
SQLState:  22005
Message:  An attempt was made to get a data value of type 'SMALLINT' from a data value of type 'java.lang.Short'.
ErrorCode:  2
SQL Exception: An attempt was made to get a data value of type 'SMALLINT' from a data value of type 'java.lang.Short'.
	at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
	at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
	at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
	at org.apache.derby.impl.jdbc.EmbedConnection.newSQLException(Unknown Source)
	at org.apache.derby.impl.jdbc.ConnectionChild.newSQLException(Unknown Source)
	at org.apache.derby.impl.jdbc.EmbedPreparedStatement.dataTypeConversion(Unknown Source)
	at org.apache.derby.impl.jdbc.EmbedPreparedStatement.setObject(Unknown Source)
Tested on Derby 10.1.1.0 and 10.1.3.1. The same test runs fine in network mode.

  
  
  

Re: In Derby SQL Authorization, is drop view the only way to drop a view created by a dba? Will revoke privilege ever drop such a view?

[Daniel John Debrunner]

Mamta Satoor wrote:

> I have been thinking about some view testing and wrote a test case where
> the
> dba creates a view in a schema owned by some other user and the view is
> accessing objects from couple different schemas on which the view's schema
> owner doesn't have access to. The view creation from dba doesn't fail
> because dba can access any object in any schema and can create any
> object in
> any schema. 

Is that true, namely "because dba can access any object in any schema
and can create any object in any schema"?

I could see that being the case, but I don't see that in the functional
spec for grant/revoke.

And are we calling this user the "DBA" or the "database owner"?

Dan.

Regression Test Failure! - TinderBox_Derby 428044 - Sun DBTG

[Ole . Solberg]

[Auto-generated mail]

*TinderBox_Derby* 428044/2006-08-02 18:33:12 CEST
*derbyall*

Failed  TestsOK  Skip  Duration   Platform
---
*Jvm: 1.5*
1687686 2   171.02% SunOS-5.10_i86pc-i386
  Details in  
http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-428044.html
 
  Attempted failure analysis in
  
http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/428044.html
 

Changes in  
http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/428044.txt
 

( All results in http://www.multinet.no/~solberg/public/Apache/index.html ) 

Heads up: procedureInTrigger.sql for j9 will likely fail

[David Van Couvering]

I just checked in revision 42818, where I added a comment to 
procedureInTrigger.sql.  I noticed there is a procedureInTrigger.out 
that is specific to the j9 vm, so this will likely cause a failure with 
the j9 tests.  I don't have a j9 vm so I couldn't fix this.  Someone who 
runs these tests will need to make this fix.


Thanks,

David

[jira] Commented: (DERBY-1629) StandardException.unexpectedUserException() does not correctly catch internally generated exceptions as of JDK 1.6

[David Van Couvering (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1629?page=comments#action_12425365 ] 

David Van Couvering commented on DERBY-1629:


Added a comment to the procedureInTrigger.sql script and fixed the main master 
file.  Also added a master file specific to jdk16.  
I noticed procedureInTrigger.out also exists in a j9-specific directory, but as 
I don' t have the j9 VM to verify I didn't try to fix this file.

Committed revision 42818

> StandardException.unexpectedUserException() does not correctly catch 
> internally generated exceptions as of JDK 1.6
> --
>
> Key: DERBY-1629
> URL: http://issues.apache.org/jira/browse/DERBY-1629
> Project: Derby
>  Issue Type: Bug
>Reporter: David Van Couvering
>Priority: Minor
> Fix For: 10.2.0.0
>
>
> In Java SE 6 runtime environments, an application may not get the SQL 
> Exception with SQL State 38000 when execution of a trigger or procedure fails 
> with an exception caused by Derby internals.  Instead, they will get the 
> underlying exception with it's SQL State.  For an example of this, see 
> lang/procedureInTrigger.sql, which has different output for Java SE 6 
> (encoded in the master/jdk16/procedureInTrigger.out file) than for other Java 
> SE runtimes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1628) Update name of driver - "IBM DB2 JDBC Universal Driver" to "IBM DB2 Driver for JDBC"

[Laura Stewart (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1628?page=all ]

Laura Stewart updated DERBY-1628:
-

Attachment: derby1628.diff
cadminapps810777.html
radminapps810699.html

Attaching a patch for this issue.  There are 2 external files and one internal 
file (a ditamap file) that are impacted. The external files are also attached.

In addition to updating the name of the driver,  I :
1. Added a shortdesc (short description) to each file. Short descriptions 
appear when you hover over a link to a file and give you an idea of what is 
contained in a file before you click the link. 
2. Added index entries (in the indexterm tags) that are part of the prolog. 
This will be useful when we can display an index --- Please review the terms 
that I added !!!
3. Made "Attributes" lowercase and rephrased those sentences for people for 
whom English is not there first language.
4. Changed "quotes" to quotation marks. Same reason as #3.

> Update name of driver - "IBM DB2 JDBC Universal Driver" to "IBM DB2 Driver 
> for JDBC"
> 
>
> Key: DERBY-1628
> URL: http://issues.apache.org/jira/browse/DERBY-1628
> Project: Derby
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 10.2.0.0
>Reporter: Laura Stewart
> Assigned To: Laura Stewart
>Priority: Minor
> Attachments: cadminapps810777.html, derby1628.diff, 
> radminapps810699.html
>
>
> The name of this driver is inaccurate, the name has changed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Re: Revised 10.2 plan for uncoupling the Mustang and Derby release trains

[Andrew McIntyre]

On 6/30/06, Jean T. Anderson <[EMAIL PROTECTED]> wrote:

Rick's plan looks good to me as long as the license is resolved -- and
it looks like it will be (with time to spare) given Lance's
clarification of the mid July target in
http://www.nabble.com/Re%3A-Revised-10.2-plan-for-uncoupling-the-Mustang-and-Derby-release-trains-p5125470.html


Hadn't seen it mentioned on the list yet, but I checked and the
JSR-221 spec license now includes the language about marking
applications written to the specification with a notice. The language
is much clearer than the previous spec license. Thanks, Lance!

It's probably a good idea to add the notice required in the new spec
license to this page:

http://www.multinet.no/~solberg/public/Apache/DerbyJDK16/builds/

andrew

Re: Question around type in DRDA(Re: [jira] Commented: (DERBY-1610) Engine take it as type compatibility error to update column typed as CHAR to value passed via setBinaryStream(null), though Network

[Dag H. Wanvik]

Hi,

TomohitoNakayama <[EMAIL PROTECTED]> writes:

> Concerning DERBY-1610, I'm surveying type definition part in current
> DRDA relating code.
>
> I found there exists two word "DRDA_TYPE" and "FDOCA_TYPE".
> Former was found in org.apache.derby.iapi.reference.DRDAConstants and
> latter was found in org.apache.derby.client.net.FdocaConstants.
>
> The latter seems to be FTYPE defined in FD:OCA Specifications.
> However I'm not sure what former is
>
> Does any one know what is DRDA_TYPE is ?

The DRDA_TYPE values in DRDAConstants correspond to the meta data
reference values, cf. section 5.7 "FD:OCA Meta Data Summary", table
5-11 "MDD References Used in Early Environmental Descriptors" in
"DRDA, Version 3, Volume 1".

Dag

[jira] Commented: (DERBY-1548) Document builtin functions - ACOS, ASIN, ATAN, COS, SIN, TAN, PI, DEGREES, RADIANS, EXP, LN, LOG, LOG10, CEIL, CEILING, FLOOR

[Laura Stewart (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1548?page=comments#action_12425373 ] 

Laura Stewart commented on DERBY-1548:
--

In the java class java.lang.StrictMath file, there is a description for the 
arguments that I don't understand.
"If the argument is NaN, the result is NaN."  
Is "NaN" null? 

> Document builtin functions - ACOS, ASIN, ATAN, COS, SIN, TAN, PI, DEGREES, 
> RADIANS, EXP, LN, LOG, LOG10, CEIL, CEILING, FLOOR
> -
>
> Key: DERBY-1548
> URL: http://issues.apache.org/jira/browse/DERBY-1548
> Project: Derby
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 10.2.0.0
>Reporter: Daniel John Debrunner
> Assigned To: Laura Stewart
> Attachments: MathFunctions.txt
>
>
> These built-in functions were added in DERBY-475.
> They should be added to the reference guide's built-in function section.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1548) Document builtin functions - ACOS, ASIN, ATAN, COS, SIN, TAN, PI, DEGREES, RADIANS, EXP, LN, LOG, LOG10, CEIL, CEILING, FLOOR

[Daniel John Debrunner (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1548?page=comments#action_12425377 ] 

Daniel John Debrunner commented on DERBY-1548:
--

NaN is "Not a number". Such a value cannot exist in Derby so it's not 
applicable for derby's documentation.

> Document builtin functions - ACOS, ASIN, ATAN, COS, SIN, TAN, PI, DEGREES, 
> RADIANS, EXP, LN, LOG, LOG10, CEIL, CEILING, FLOOR
> -
>
> Key: DERBY-1548
> URL: http://issues.apache.org/jira/browse/DERBY-1548
> Project: Derby
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 10.2.0.0
>Reporter: Daniel John Debrunner
> Assigned To: Laura Stewart
> Attachments: MathFunctions.txt
>
>
> These built-in functions were added in DERBY-475.
> They should be added to the reference guide's built-in function section.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1548) Document builtin functions - ACOS, ASIN, ATAN, COS, SIN, TAN, PI, DEGREES, RADIANS, EXP, LN, LOG, LOG10, CEIL, CEILING, FLOOR

[Laura Stewart (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1548?page=comments#action_12425382 ] 

Laura Stewart commented on DERBY-1548:
--

One more thing in the In the java class java.lang.StrictMath file that I need 
to clarify.
That file uses "toRadians" and "toDegrees" as the names for the functions.  Is 
Derby using
just RADIANS and DEGREES as the names of these functions... or do the names 
need to match the java class?

> Document builtin functions - ACOS, ASIN, ATAN, COS, SIN, TAN, PI, DEGREES, 
> RADIANS, EXP, LN, LOG, LOG10, CEIL, CEILING, FLOOR
> -
>
> Key: DERBY-1548
> URL: http://issues.apache.org/jira/browse/DERBY-1548
> Project: Derby
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 10.2.0.0
>Reporter: Daniel John Debrunner
> Assigned To: Laura Stewart
> Attachments: MathFunctions.txt
>
>
> These built-in functions were added in DERBY-475.
> They should be added to the reference guide's built-in function section.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1548) Document builtin functions - ACOS, ASIN, ATAN, COS, SIN, TAN, PI, DEGREES, RADIANS, EXP, LN, LOG, LOG10, CEIL, CEILING, FLOOR

[Daniel John Debrunner (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1548?page=comments#action_12425383 ] 

Daniel John Debrunner commented on DERBY-1548:
--

The names of the DERBY functions are correct in the summary of this issue, ie. 
RADIANS and DEGREES .

> Document builtin functions - ACOS, ASIN, ATAN, COS, SIN, TAN, PI, DEGREES, 
> RADIANS, EXP, LN, LOG, LOG10, CEIL, CEILING, FLOOR
> -
>
> Key: DERBY-1548
> URL: http://issues.apache.org/jira/browse/DERBY-1548
> Project: Derby
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 10.2.0.0
>Reporter: Daniel John Debrunner
> Assigned To: Laura Stewart
> Attachments: MathFunctions.txt
>
>
> These built-in functions were added in DERBY-475.
> They should be added to the reference guide's built-in function section.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1521) Upgrade test needs to be enhanced to test grant revoke

[Daniel John Debrunner (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1521?page=comments#action_12425384 ] 

Daniel John Debrunner commented on DERBY-1521:
--

Patch d1521-patch2-v1.diff committed - Committed revision 428160. Thanks Deepa

> Upgrade test needs to be enhanced to test grant revoke
> --
>
> Key: DERBY-1521
> URL: http://issues.apache.org/jira/browse/DERBY-1521
> Project: Derby
>  Issue Type: Improvement
>  Components: Test
>Affects Versions: 10.2.0.0
>Reporter: Mamta A. Satoor
> Assigned To: Deepa Remesh
> Fix For: 10.2.0.0
>
> Attachments: d1521-patch1-v1.diff, d1521-patch1-v1.status, 
> d1521-patch2-draft.diff, d1521-patch2-v1.diff, d1521-patch2-v1.status
>
>
> Grant Revoke is one of the features targeted for 10.2 Release. The upgrade 
> test should be modified to test this feature with various upgrade scenarios 
> to make sure everything works fine.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Enforcing length restrictions for streams of unknown length

[Kristian Waagan]

Mike Matrigali wrote:
> 
> 
> Mike Matrigali wrote:
>> This may or may not work, not sure.  Here is stuff to be aware of.
>> If you do this approach, the store will go ahead and insert and log
>> data into the database.  For it to work correctly you will
>> have to make sure that the resulting error from the limit at least
>> aborts the statement which is doing the insert/update.
>>
>> My guess is that you are going to get some sort of STORE exception
>> with the limit exception wrapped below it.  I would not be surprised
>> if the current store exception is more severe than you want it to
>> be as the current code does not expect this error - you may have
>> to define a new less severe error in this case.  There may be more
>> than one exception path.  Make sure to test the case where
>> the inserted blob exceeds the page size and the case where the
>> inserted blob is less than the page size. 
> 
> By severity I meant that store may currently raise a transaction or
> system level exception.  A good test would be to have a multi-statement
> transaction and make sure this error does not back out an earlier
> statement in the uncommitted transation.
> 

Hello Mike,

Thank you very much for the information.
I think I can implement the upper layers of what I plan pretty fast.
I'll go ahead and see what happens. I was hoping to avoid making changes
in the store, but based on your information I fear that has to done.

I appreciate the help on which test scenarios I should write tests for.
If you, or anyone else, have more of them, keep'em coming :)

I'll report back on my findings as soon as possible, hopefully in a few
days.



Regards,
-- 
Kristian

[jira] Resolved: (DERBY-1628) Update name of driver - "IBM DB2 JDBC Universal Driver" to "IBM DB2 Driver for JDBC"

[Jean T. Anderson (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1628?page=all ]

Jean T. Anderson resolved DERBY-1628.
-

Fix Version/s: 10.2.0.0
   Resolution: Fixed

Committed patch derby1628.diff revision 428167.

> Update name of driver - "IBM DB2 JDBC Universal Driver" to "IBM DB2 Driver 
> for JDBC"
> 
>
> Key: DERBY-1628
> URL: http://issues.apache.org/jira/browse/DERBY-1628
> Project: Derby
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 10.2.0.0
>Reporter: Laura Stewart
> Assigned To: Laura Stewart
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: cadminapps810777.html, derby1628.diff, 
> radminapps810699.html
>
>
> The name of this driver is inaccurate, the name has changed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (DERBY-1628) Update name of driver - "IBM DB2 JDBC Universal Driver" to "IBM DB2 Driver for JDBC"

[Laura Stewart (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1628?page=all ]

Laura Stewart closed DERBY-1628.



> Update name of driver - "IBM DB2 JDBC Universal Driver" to "IBM DB2 Driver 
> for JDBC"
> 
>
> Key: DERBY-1628
> URL: http://issues.apache.org/jira/browse/DERBY-1628
> Project: Derby
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 10.2.0.0
>Reporter: Laura Stewart
> Assigned To: Laura Stewart
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: cadminapps810777.html, derby1628.diff, 
> radminapps810699.html
>
>
> The name of this driver is inaccurate, the name has changed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (DERBY-1634) Documented syntax for storing jar files in a db has syntax errors

[Kathey Marsden (JIRA)]

Documented syntax for  storing jar files in a db has syntax errors
--

 Key: DERBY-1634
 URL: http://issues.apache.org/jira/browse/DERBY-1634
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.1.3.1
Reporter: Kathey Marsden
Priority: Minor
 Fix For: 10.2.0.0


The 'Adding a jar 
file' section (link below) is missing a J from the "SQL." 
portion (should be SQLJ).  The 'Removing a jar file' and 
'Adding a jar file' sections have 3 parameters in the syntax 
description and should only have 2 parameters. 

http://db.apache.org/derby/docs/10.1/tools/ttoolsjarload1002986.html
http://db.apache.org/derby/docs/10.1/tools/ttoolsjarload1003059.html

It would also be good to clarify the meaning of the parameters.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1614) Test harness overrides heap size settings when starting Network Server

[Myrna van Lunteren (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1614?page=comments#action_12425391 ] 

Myrna van Lunteren commented on DERBY-1614:
---

I reviewed the patch, and the testing described. (Did not do any testing 
myself).

I think this section of code originally just meant to ensure networkserver had 
enough juice to get going with.

If I summarize correctly, this patch, apart from fixing up the flawed logic of 
my change in this area for DERBY-1091, implements code to not interfere with 
the heap settings whenever it looks like specific settings in either ms or mx 
are passed in. I think this is a good improvement.

Once derbyall results are in I think this can be committed.

> Test harness overrides heap size settings when starting Network Server
> --
>
> Key: DERBY-1614
> URL: http://issues.apache.org/jira/browse/DERBY-1614
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.2.0.0
> Environment: Test frameworks DerbyNet and DerbyNetClient
>Reporter: John H. Embretsen
> Assigned To: John H. Embretsen
> Fix For: 10.2.0.0
>
> Attachments: DERBY-1614_v1.diff
>
>
> Test specific heap size settings can be passed to the test harness using the 
> jvmflags system property, for example in a _app.properties file or 
> at the command line when starting a test, e.g "-Djvmflags=-Xms32m^-Xmx32m".
> The test harness almost always overrides such settings when starting a new 
> Network Server using the 
> org.apache.derbyTesting.functionTests.harness.NetServer class of the test 
> harness. Currently, if _either_ -ms _or_ -Xms is missing from the jvmflags, 
> NetServer.start() adds -ms16777216. Also, if _either_ -mx _or_ -Xmx is 
> missing from the jvmflags, NetServer.start() adds -ms33554432. This has been 
> the case since SVN revision 420048 (July 8, 2006).
> Earlier revisions did not override the heap settings unless the newer -Xms or 
> -Xmx flags were used instead of the -ms and -mx flags. A patch for DERBY-1091 
> attempted (among other things) to make the harness recognize the newer flags 
> as well as the older flags, but the resulting behavior is (most likely) not 
> as intended. 
> If a test is run in either the DerbyNet framework or the DerbyNetClient 
> framework, the test-specific JVM flags should (probably) be used for the 
> Network Server JVM as well as the test JVM. Currently, even if non-default 
> heap size flags are passed to the harness, the server JVM will ignore these 
> settings since the harness adds -ms and/or -mx flags _after_ all other heap 
> flags. The exception is if both new and old versions of heap flags are passed 
> to the harness, e.g:
> jvmflags=-ms32m^-Xms32m^-mx128m^-Xmx128m
> Here is the code causing this behaviour:
> if (setJvmFlags && ((jvmflags.indexOf("-ms") == -1) || 
> (jvmflags.indexOf("-Xms") == -1)))
>  // only setMs if no starting memory was given
>  jvm.setMs(16*1024*1024); // -ms16m
> if (setJvmFlags && ((jvmflags.indexOf("-mx") == -1) || 
> (jvmflags.indexOf("-Xmx") == -1)))
>  // only setMx if no max memory was given
>  jvm.setMx(32*1024*1024); // -mx32m

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1544) Address remaining upgrade task(s) to complete full upgrade mechanism for GRANT/REVOKE, specifically with changing database owner name from 'DBA' to authorizationId of user

[Deepa Remesh (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1544?page=all ]

Deepa Remesh updated DERBY-1544:


Attachment: d1544-patch1-v1.diff
d1544-patch1-v1.status

Attaching a patch 'd1544-patch1-v1.diff' which is same as the draft patch + a 
test. This patch solves the first part of this sub-task. 

This patch modifies only DataDictionaryImpl.updateSchemaAuth method which is 
used only in the upgrade path. Hence I have only run the upgrade test with this 
patch. I also verified that the newly added check in the test fails without the 
patch and passes with it.

Please review/commit this patch. Thanks.

> Address remaining upgrade task(s) to complete full upgrade mechanism for 
> GRANT/REVOKE, specifically with changing database owner name from 'DBA' to 
> authorizationId of user invoking upgrade.
> -
>
> Key: DERBY-1544
> URL: http://issues.apache.org/jira/browse/DERBY-1544
> Project: Derby
>  Issue Type: Sub-task
>  Components: SQL
>Affects Versions: 10.2.0.0
> Environment: generic
>Reporter: Satheesh Bandaram
> Assigned To: Deepa Remesh
> Fix For: 10.2.0.0
>
> Attachments: d1544-patch1-draft.diff, d1544-patch1-v1.diff, 
> d1544-patch1-v1.status
>
>
> Upgrading a database from 10.1 to 10.2 should automatically change database 
> owner, recorded as owner of system schemas in sysschemas, from pseudo user 
> 'DBA' to authorizationID of the user attempting upgrade. 
> Another upgrade change I am thinking about is to grant execute privilege to 5 
> system routines that by default have execute privilege to public when a new 
> database is created. Five system routines, two compress routines and three 
> statistics related routines are given execute privilege to public when a new 
> 10.2 database is created. This is not done when a 10.1 database is upgraded 
> to 10.2 and probably good to include these privileges during database upgrade.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1544) Address remaining upgrade task(s) to complete full upgrade mechanism for GRANT/REVOKE, specifically with changing database owner name from 'DBA' to authorizationId of user

[Deepa Remesh (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1544?page=all ]

Deepa Remesh updated DERBY-1544:


Derby Info: [Patch Available]

> Address remaining upgrade task(s) to complete full upgrade mechanism for 
> GRANT/REVOKE, specifically with changing database owner name from 'DBA' to 
> authorizationId of user invoking upgrade.
> -
>
> Key: DERBY-1544
> URL: http://issues.apache.org/jira/browse/DERBY-1544
> Project: Derby
>  Issue Type: Sub-task
>  Components: SQL
>Affects Versions: 10.2.0.0
> Environment: generic
>Reporter: Satheesh Bandaram
> Assigned To: Deepa Remesh
> Fix For: 10.2.0.0
>
> Attachments: d1544-patch1-draft.diff, d1544-patch1-v1.diff, 
> d1544-patch1-v1.status
>
>
> Upgrading a database from 10.1 to 10.2 should automatically change database 
> owner, recorded as owner of system schemas in sysschemas, from pseudo user 
> 'DBA' to authorizationID of the user attempting upgrade. 
> Another upgrade change I am thinking about is to grant execute privilege to 5 
> system routines that by default have execute privilege to public when a new 
> database is created. Five system routines, two compress routines and three 
> statistics related routines are given execute privilege to public when a new 
> 10.2 database is created. This is not done when a 10.1 database is upgraded 
> to 10.2 and probably good to include these privileges during database upgrade.
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1521) Upgrade test needs to be enhanced to test grant revoke

[Deepa Remesh (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1521?page=all ]

Deepa Remesh updated DERBY-1521:


Derby Info:   (was: [Patch Available])

> Upgrade test needs to be enhanced to test grant revoke
> --
>
> Key: DERBY-1521
> URL: http://issues.apache.org/jira/browse/DERBY-1521
> Project: Derby
>  Issue Type: Improvement
>  Components: Test
>Affects Versions: 10.2.0.0
>Reporter: Mamta A. Satoor
> Assigned To: Deepa Remesh
> Fix For: 10.2.0.0
>
> Attachments: d1521-patch1-v1.diff, d1521-patch1-v1.status, 
> d1521-patch2-draft.diff, d1521-patch2-v1.diff, d1521-patch2-v1.status
>
>
> Grant Revoke is one of the features targeted for 10.2 Release. The upgrade 
> test should be modified to test this feature with various upgrade scenarios 
> to make sure everything works fine.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1320) Test lang/procedure.java fails with ibm1.5 jvm

[Manjula Kutty (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1320?page=all ]

Manjula Kutty updated DERBY-1320:
-

Attachment: svn_diff.txt

Hi Knut,

Thanks for your valuable suggestions. As per that I had modified the patch. The 
white spaces are because I had edited the file using textpad (bad idea). For 
this patch I had edited the file using vi. And looked fine to me. Please lep me 
know if there is any problem.

> Test lang/procedure.java fails with ibm1.5 jvm
> --
>
> Key: DERBY-1320
> URL: http://issues.apache.org/jira/browse/DERBY-1320
> Project: Derby
>  Issue Type: Test
>  Components: Test, Regression Test Failure
>Affects Versions: 10.2.0.0
> Environment: IBM 1.5 JVM /linux 
>Reporter: Sunitha Kambhampati
> Assigned To: Manjula Kutty
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: procedure.diff, procedure.diff, procedure.java, 
> procedure.stat, svn_diff.txt, svn_stat.txt
>
>
> lang/procedure.java fails on IBM1.5 jvm on linux machine.I spoke to 
> Manjula who filed DERBY-1108 that this is related to that issue and is a JVM 
> bug. The JVM team has been notified.Please note: I have marked this as a 
> Regression Test Failure although this test has not passed with IBM 1.5 JVM 
> atleast in our nightly regression test runs,  so it is not a regression of 
> the product. 
> diff:
> * Diff file derbyall/derbylang/procedure.diff
> *** Start: procedure jdk1.5.0 derbyall:derbylang 2006-05-10 22:17:16 ***
> 1018 del
> < testImplicitClose(): PASSED
> 1018 add
> > testImplicitClose(): FAILED (no exception thrown)
> Test Failed.
> *** End:   procedure jdk1.5.0 derbyall:derbylang 2006-05-10 22:17:31 ***
> here is machine info.
> -- Java Information --
> Java Version:1.5.0
> Java Vendor: IBM Corporation
> Java home:   /local1/cloudtst/dev/src/ibm15/jre
> Java classpath:  
> /local1/cloudtst/dev/src/jars/insane/derby.jar:/local1/cloudtst/dev/src/jars/insane/derbytools.jar:/local1/cloudtst/dev/src/jars/insane/derbynet.jar:/local1/cloudtst/dev/src/jars/insane/derbyclient.jar:/local1/cloudtst/dev/src/jars/insane/derbyTesting.jar:/local1/cloudtst/dev/src/jcc/db2jcc.jar:/local1/cloudtst/dev/src/jcc/db2jcc_license_c.jar:/local1/cloudtst/dev/src/jars/insane/derbyTesting.jar:/local1/cloudtst/dev/src/tools/java/jakarta-oro-2.0.8.jar:/local1/cloudtst/dev/src/tools/java/junit.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_de_DE.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_es.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_fr.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_it.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_ja_JP.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_ko_KR.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_pt_BR.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_zh_CN.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_zh_TW.jar:/local1/cloudtst/dev/src/jars/insane/derbyrun.jar:
> OS name: Linux
> OS architecture: x86
> OS version:  2.6.5-7.252-bigsmp
> Java user name:  cloudtst
> Java user home:  /u/cloudtst
> Java user dir:   
> /local1/cloudtst/dev/src/NightlyBuildResults.2006-05-10/ibm15_derbyall
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.5
> - Derby Information 
> JRE - JDBC: J2SE 5.0 - JDBC 3.0
> [/local1/cloudtst/dev/src/jars/insane/derby.jar] 10.2.0.0 alpha - (405653)
> [/local1/cloudtst/dev/src/jars/insane/derbytools.jar] 10.2.0.0 alpha - 
> (405653)
> [/local1/cloudtst/dev/src/jars/insane/derbynet.jar] 10.2.0.0 alpha - (405653)
> [/local1/cloudtst/dev/src/jars/insane/derbyclient.jar] 10.2.0.0 alpha - 
> (405653)
> [/local1/cloudtst/dev/src/jcc/db2jcc.jar] 2.6 - (90)
> [/local1/cloudtst/dev/src/jcc/db2jcc_license_c.jar] 2.6 - (90)
> --

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1320) Test lang/procedure.java fails with ibm1.5 jvm

[Manjula Kutty (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1320?page=all ]

Manjula Kutty updated DERBY-1320:
-

Attachment: svn_stat.txt

> Test lang/procedure.java fails with ibm1.5 jvm
> --
>
> Key: DERBY-1320
> URL: http://issues.apache.org/jira/browse/DERBY-1320
> Project: Derby
>  Issue Type: Test
>  Components: Test, Regression Test Failure
>Affects Versions: 10.2.0.0
> Environment: IBM 1.5 JVM /linux 
>Reporter: Sunitha Kambhampati
> Assigned To: Manjula Kutty
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: procedure.diff, procedure.diff, procedure.java, 
> procedure.stat, svn_diff.txt, svn_stat.txt
>
>
> lang/procedure.java fails on IBM1.5 jvm on linux machine.I spoke to 
> Manjula who filed DERBY-1108 that this is related to that issue and is a JVM 
> bug. The JVM team has been notified.Please note: I have marked this as a 
> Regression Test Failure although this test has not passed with IBM 1.5 JVM 
> atleast in our nightly regression test runs,  so it is not a regression of 
> the product. 
> diff:
> * Diff file derbyall/derbylang/procedure.diff
> *** Start: procedure jdk1.5.0 derbyall:derbylang 2006-05-10 22:17:16 ***
> 1018 del
> < testImplicitClose(): PASSED
> 1018 add
> > testImplicitClose(): FAILED (no exception thrown)
> Test Failed.
> *** End:   procedure jdk1.5.0 derbyall:derbylang 2006-05-10 22:17:31 ***
> here is machine info.
> -- Java Information --
> Java Version:1.5.0
> Java Vendor: IBM Corporation
> Java home:   /local1/cloudtst/dev/src/ibm15/jre
> Java classpath:  
> /local1/cloudtst/dev/src/jars/insane/derby.jar:/local1/cloudtst/dev/src/jars/insane/derbytools.jar:/local1/cloudtst/dev/src/jars/insane/derbynet.jar:/local1/cloudtst/dev/src/jars/insane/derbyclient.jar:/local1/cloudtst/dev/src/jars/insane/derbyTesting.jar:/local1/cloudtst/dev/src/jcc/db2jcc.jar:/local1/cloudtst/dev/src/jcc/db2jcc_license_c.jar:/local1/cloudtst/dev/src/jars/insane/derbyTesting.jar:/local1/cloudtst/dev/src/tools/java/jakarta-oro-2.0.8.jar:/local1/cloudtst/dev/src/tools/java/junit.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_de_DE.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_es.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_fr.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_it.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_ja_JP.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_ko_KR.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_pt_BR.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_zh_CN.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_zh_TW.jar:/local1/cloudtst/dev/src/jars/insane/derbyrun.jar:
> OS name: Linux
> OS architecture: x86
> OS version:  2.6.5-7.252-bigsmp
> Java user name:  cloudtst
> Java user home:  /u/cloudtst
> Java user dir:   
> /local1/cloudtst/dev/src/NightlyBuildResults.2006-05-10/ibm15_derbyall
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.5
> - Derby Information 
> JRE - JDBC: J2SE 5.0 - JDBC 3.0
> [/local1/cloudtst/dev/src/jars/insane/derby.jar] 10.2.0.0 alpha - (405653)
> [/local1/cloudtst/dev/src/jars/insane/derbytools.jar] 10.2.0.0 alpha - 
> (405653)
> [/local1/cloudtst/dev/src/jars/insane/derbynet.jar] 10.2.0.0 alpha - (405653)
> [/local1/cloudtst/dev/src/jars/insane/derbyclient.jar] 10.2.0.0 alpha - 
> (405653)
> [/local1/cloudtst/dev/src/jcc/db2jcc.jar] 2.6 - (90)
> [/local1/cloudtst/dev/src/jcc/db2jcc_license_c.jar] 2.6 - (90)
> --

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1614) Test harness overrides heap size settings when starting Network Server

[Andrew McIntyre (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1614?page=comments#action_12425396 ] 

Andrew McIntyre commented on DERBY-1614:


This looks good to me as well. My only comment is that the 
!jvmName.equals("jview") can be removed. I don't think we need to be worrying 
about whether or not the test harness runs with jview anymore. :-)

> Test harness overrides heap size settings when starting Network Server
> --
>
> Key: DERBY-1614
> URL: http://issues.apache.org/jira/browse/DERBY-1614
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.2.0.0
> Environment: Test frameworks DerbyNet and DerbyNetClient
>Reporter: John H. Embretsen
> Assigned To: John H. Embretsen
> Fix For: 10.2.0.0
>
> Attachments: DERBY-1614_v1.diff
>
>
> Test specific heap size settings can be passed to the test harness using the 
> jvmflags system property, for example in a _app.properties file or 
> at the command line when starting a test, e.g "-Djvmflags=-Xms32m^-Xmx32m".
> The test harness almost always overrides such settings when starting a new 
> Network Server using the 
> org.apache.derbyTesting.functionTests.harness.NetServer class of the test 
> harness. Currently, if _either_ -ms _or_ -Xms is missing from the jvmflags, 
> NetServer.start() adds -ms16777216. Also, if _either_ -mx _or_ -Xmx is 
> missing from the jvmflags, NetServer.start() adds -ms33554432. This has been 
> the case since SVN revision 420048 (July 8, 2006).
> Earlier revisions did not override the heap settings unless the newer -Xms or 
> -Xmx flags were used instead of the -ms and -mx flags. A patch for DERBY-1091 
> attempted (among other things) to make the harness recognize the newer flags 
> as well as the older flags, but the resulting behavior is (most likely) not 
> as intended. 
> If a test is run in either the DerbyNet framework or the DerbyNetClient 
> framework, the test-specific JVM flags should (probably) be used for the 
> Network Server JVM as well as the test JVM. Currently, even if non-default 
> heap size flags are passed to the harness, the server JVM will ignore these 
> settings since the harness adds -ms and/or -mx flags _after_ all other heap 
> flags. The exception is if both new and old versions of heap flags are passed 
> to the harness, e.g:
> jvmflags=-ms32m^-Xms32m^-mx128m^-Xmx128m
> Here is the code causing this behaviour:
> if (setJvmFlags && ((jvmflags.indexOf("-ms") == -1) || 
> (jvmflags.indexOf("-Xms") == -1)))
>  // only setMs if no starting memory was given
>  jvm.setMs(16*1024*1024); // -ms16m
> if (setJvmFlags && ((jvmflags.indexOf("-mx") == -1) || 
> (jvmflags.indexOf("-Xmx") == -1)))
>  // only setMx if no max memory was given
>  jvm.setMx(32*1024*1024); // -mx32m

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1633) Regression: The fields of views are not being calculated properly since 10.1.2.4

[A B (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1633?page=all ]

A B updated DERBY-1633:
---

Attachment: d1633_repro.sql

Attaching a simplified reproduction of the problem that does not rely on the 
database in DERBY-1205.  (But the database in DERBY-1205 allowed me to write 
this repro, so THANKS to Prasenjit for posting the database initially).

> Regression: The fields of views are not being calculated properly since 
> 10.1.2.4
> 
>
> Key: DERBY-1633
> URL: http://issues.apache.org/jira/browse/DERBY-1633
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.1.3.0, 10.1.3.1
> Environment: 2.8 GHZ dual PIV on Windows XP SP2, 2 GB memory
>Reporter: Prasenjit Sarkar
> Assigned To: A B
> Attachments: d1633_repro.sql
>
>
> Database can be assumed to be same as in Derby - 1205 Jira issue
> SELECT PORT1.PORT_ID FROM T_RES_PORT PORT1, T_VIEW_ENTITY2PORT ENTITY2PORT 
> WHERE ENTITY2PORT.PORT_ID = PORT1.PORT_ID
> This works fine in 10.1.2.1 but fails thereafter complaining that Comparison 
> between INTEGER and CHAR is not supported
> for some reason, it thinks one of the PORT_ID columns is a character, when in 
> reality both are integers.
>   SELECT DISTINCT 
>   ZONE.ZONE_ID ZONE_ID, 
>PORT2ZONE.ZONE_MEMBER_ID  
>   FROM  
>T_RES_ZONE ZONE left outer join T_VIEW_PORT2ZONE 
> PORT2ZONE on  
>ZONE.ZONE_ID = PORT2ZONE.ZONE_ID   ,  T_RES_FABRIC 
> FABRIC 
> In this query, it is complaining that one of the columns is a VARCHAR and 
> cannot be compared to INTEGER, when clearly this is not the case...
> Same issue

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Regression Test Failure! - TinderBox_Derby 428125 - Sun DBTG

[Ole . Solberg]

[Auto-generated mail]

*TinderBox_Derby* 428125/2006-08-02 22:13:30 CEST
*derbyall*

Failed  TestsOK  Skip  Duration   Platform
---
*Jvm: 1.5*
1687686 2   186.21% SunOS-5.10_i86pc-i386
  Details in  
http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-428125.html
 
  Attempted failure analysis in
  
http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/428125.html
 

Changes in  
http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/428125.txt
 

( All results in http://www.multinet.no/~solberg/public/Apache/index.html ) 

[jira] Updated: (DERBY-1424) Build derbyclient.jar from a dependency list generated by classlister

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1424?page=all ]

Andrew McIntyre updated DERBY-1424:
---

Attachment: derby-1424-v1.diff

Attaching a patch for this issue. With the patch I'm seeing some odd behavior 
with jdbc4/TestConnectionMethods.java that I'm not sure how it could be related 
to my patch, since it only involves Network Server code. But, sure enough, it 
passes without the patch and fails with the patch. This test starts the network 
server, but then NetworkServerControl.ping() is apparently unable to connect to 
the network server. I get errors like:

> INFO: ping returned: java.lang.Exception: DRDA_NoIO.S:Could not connect to 
> Derby Network Server on host 127.0.0.1, port 1527.
> FAIL: Failed to start network server

and other communication fails to reach the server as well. I can verfy that the 
server has in fact been started. All other tests except 
derbynet/testSecMec.java, but that also fails on my machine without the patch, 
so I think that's something environmental on my machine.

If anyone has any insight into what might be going on here, or has time to try 
out the patch, that would be great. It has turned up several unused classes in 
the client, which I'll post about separately on the list. 

> Build derbyclient.jar from a dependency list generated by classlister
> -
>
> Key: DERBY-1424
> URL: http://issues.apache.org/jira/browse/DERBY-1424
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Affects Versions: 10.2.0.0
>Reporter: Andrew McIntyre
> Assigned To: Andrew McIntyre
> Fix For: 10.2.0.0
>
> Attachments: derby-1424-v1.diff, derbyclient_classlister.patch
>
>
> Currently, derbyclient.jar is built from a hardcoded list of classes in the 
> top-level build.xml file. This causes a few unnecessary and unwanted 
> classfiles to be added to the insane jar files, such as SanityManager and 
> some of the reference files. derbyclient.jar should be built from a 
> dependency list generated by classlister, similar to how the other jars are 
> built.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (DERBY-1635) stress.multi fails on 10.1/ibm131/jcc2.4

[Sunitha Kambhampati (JIRA)]

stress.multi fails on 10.1/ibm131/jcc2.4 
-

 Key: DERBY-1635
 URL: http://issues.apache.org/jira/browse/DERBY-1635
 Project: Derby
  Issue Type: Bug
  Components: Regression Test Failure
Affects Versions: 10.1.3.2
 Environment: windows machine. 
Reporter: Sunitha Kambhampati
Priority: Minor


* Diff file derbynetmats/DerbyNet/multi/stress.diff
*** Start: stress jdk1.3.1 DerbyNet derbynetmats:multi 2006-07-09 01:24:15 ***
6 del
< TEST CASE SUMMARY: normal termination
7 del
< ...running last checks via final.sql
7 add
> TEST CASE SUMMARY: abnormal termination due to error(s) -- see test log 
> (./stress/stress.log) for details 
Test Failed.
*** End:   stress jdk1.3.1 DerbyNet derbynetmats:multi 2006-07-09 01:28:50 ***
--


Generating report for RunSuite derbynetmats  null null DerbyNet true 
-- Java Information --
Java Version:1.3.1
Java Vendor: IBM Corporation
Java home:   D:\cloudtst\jartest\ibm131\jre
Java classpath:  
D:/cloudtst/jartest/classes/derby.jar;D:/cloudtst/jartest/classes/derbytools.jar;D:/cloudtst/jartest/classes/derbynet.jar;D:/cloudtst/jartest/classes/functionTests.jar;D:/cloudtst/jartest/classes/derbyTesting.jar;D:/cloudtst/jartest/tools/java/jndi/fscontext.jar;D:/cloudtst/jartest/drda/jcc/2.4_latest/db2jcc.jar;D:/cloudtst/jartest/drda/jcc/2.4_latest/db2jcc_license_c.jar;D:/cloudtst/jartest/classes/derbyLocale_zh_TW.jar;D:/cloudtst/jartest/classes/derbyLocale_zh_CN.jar;D:/cloudtst/jartest/classes/derbyLocale_pt_BR.jar;D:/cloudtst/jartest/classes/derbyLocale_ko_KR.jar;D:/cloudtst/jartest/classes/derbyLocale_ja_JP.jar;D:/cloudtst/jartest/classes/derbyLocale_it.jar;D:/cloudtst/jartest/classes/derbyLocale_fr.jar;D:/cloudtst/jartest/classes/derbyLocale_es.jar;D:/cloudtst/jartest/classes/derbyLocale_de_DE.jar;
OS name: Windows 2000
OS architecture: x86
OS version:  5.0
Java user name:  cloudtest
Java user home:  C:\Documents and Settings\cloudtest
Java user dir:   
D:\cloudtst\jartest\JarResults.2006-07-07\ibm131_derbynetmats_jcc_2.4_latest
java.specification.name: Java Platform API Specification
java.specification.version: 1.3
- Derby Information 
JRE - JDBC: J2SE 1.3 - JDBC 2.1
[D:\cloudtst\jartest\classes\derby.jar] 10.1.3.2 - (419765)
[D:\cloudtst\jartest\classes\derbytools.jar] 10.1.3.2 - (419765)
[D:\cloudtst\jartest\classes\derbynet.jar] 10.1.3.2 - (419765)
[D:\cloudtst\jartest\drda\jcc\2.4_latest\db2jcc.jar] 2.4 - (19)
[D:\cloudtst\jartest\drda\jcc\2.4_latest\db2jcc_license_c.jar] 2.4 - (19)
--


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1156) allow the encrypting of an existing unencrypted db and allow the re-encrypting of an existing encrypted db

[Suresh Thalamati (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1156?page=all ]

Suresh Thalamati updated DERBY-1156:


Attachment: reencryptspec_1.html

Minor updated to the spec. 


> allow the encrypting of an existing unencrypted db and allow the 
> re-encrypting of an existing encrypted db
> --
>
> Key: DERBY-1156
> URL: http://issues.apache.org/jira/browse/DERBY-1156
> Project: Derby
>  Issue Type: Improvement
>  Components: Store
>Affects Versions: 10.1.2.3
>Reporter: Mike Matrigali
> Assigned To: Suresh Thalamati
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: encryptspec.html, reencrypt_1.diff, reencrypt_2.diff, 
> reencrypt_3.diff, reencrypt_4.diff, reencrypt_5.diff, reencryptspec_1.html
>
>
> encrypted database to be re-encrypted with a new password.
> Here are some ideas for an initial implementation.
> The easiest way to do this is to make sure we have exclusive access to the
> data and that no log is required in the new copy of the db.  I want to avoid
> the log as it also is encrypted.  Here is my VERY high level plan:
> 1) Force exclusive access by putting all the work in the low level store,
>offline boot method.  We will do redo recovery as usual, but at the end
>there will be an entry point to do the copy/encrypt operation.
> copy/encrypt process:
> 0) The request to encrypt/re-encrypt the db will be handled with a new set
>of url flags passed into store at boot time.  The new flags will provide
>the same inputs as the current encrypt flags.  So at high level the
>request will be "connect db old_encrypt_url_flags; new_encrypt_url_flags".
>TODO - provide exact new flag syntax.
> 1) Open a transaction do all logged work to do the encryption.  All logging
>will be done with existing encryption.
> 2) Copy and encrypt every db file in the database.  The target files will
>be in the data directory.  There will be a new suffix to track the new
>files, similar to the current process used for handling drop table in
>a transaction consistent manner without logging the entire table to the 
> log.
>Entire encrypted destination file is guaranteed synced to disk before
>transaction commits.  I don't think this part needs to be logged.
>Files will be read from the cache using existing mechanism and written
>directly into new encrypted files (new encrypted data does not end up in
>the cache).
> 3) Switch encrypted files for old files.  Do this under a new log operation
>so the process can be correctly rolled back if the encrypt db operation
>transaction fails.  Rollback will do file at a time switches, no reading
>of encrypted data is necessary.
> 4) log a "change encryption of db" log record, but do not update
>system.properties with the change.
> 5) commit transaction.
> 6) update system.properties and sync changes.
> 7) TODO - need someway to handle crash between steps 5 and 6.
> 6) checkpoint all data, at this point guaranteed that there is no outstanding
>transaction, so after checkpoint is done there is no need for the log.
> ISSUES:
> o there probably should be something that catches a request to encrypt to
>   whatever db was already encrypted with.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (DERBY-1636) document encryption of an un-encrypted database and re-encryption with new password/key.

[Suresh Thalamati (JIRA)]

document   encryption of an un-encrypted database and re-encryption with new 
password/key. 
---

 Key: DERBY-1636
 URL: http://issues.apache.org/jira/browse/DERBY-1636
 Project: Derby
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 10.2.0.0
Reporter: Suresh Thalamati
 Attachments: reencryptspec_1.html

document   encryption of an un-encrypted database and re-encryption with new 
password/key. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1636) document encryption of an un-encrypted database and re-encryption with new password/key.

[Suresh Thalamati (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1636?page=all ]

Suresh Thalamati updated DERBY-1636:


Attachment: reencryptspec_1.html

> document   encryption of an un-encrypted database and re-encryption with new 
> password/key.
> --
>
> Key: DERBY-1636
> URL: http://issues.apache.org/jira/browse/DERBY-1636
> Project: Derby
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 10.2.0.0
>Reporter: Suresh Thalamati
> Attachments: reencryptspec_1.html
>
>
> document   encryption of an un-encrypted database and re-encryption with new 
> password/key. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1635) stress.multi fails on 10.1/ibm131/jcc2.4

[Sunitha Kambhampati (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1635?page=comments#action_12425417 ] 

Sunitha Kambhampati commented on DERBY-1635:


Please note: For some reason I was looking at an old test run history - for the 
week of 07/07 and came across this failure.   With a recent build  10.1.3.2 - 
(426357)., this test does not fail. 
 

> stress.multi fails on 10.1/ibm131/jcc2.4
> 
>
> Key: DERBY-1635
> URL: http://issues.apache.org/jira/browse/DERBY-1635
> Project: Derby
>  Issue Type: Bug
>  Components: Regression Test Failure
>Affects Versions: 10.1.3.2
> Environment: windows machine. 
>Reporter: Sunitha Kambhampati
>Priority: Minor
>
> * Diff file derbynetmats/DerbyNet/multi/stress.diff
> *** Start: stress jdk1.3.1 DerbyNet derbynetmats:multi 2006-07-09 01:24:15 ***
> 6 del
> < TEST CASE SUMMARY: normal termination
> 7 del
> < ...running last checks via final.sql
> 7 add
> > TEST CASE SUMMARY: abnormal termination due to error(s) -- see test log 
> > (./stress/stress.log) for details 
> Test Failed.
> *** End:   stress jdk1.3.1 DerbyNet derbynetmats:multi 2006-07-09 01:28:50 ***
> --
> Generating report for RunSuite derbynetmats  null null DerbyNet true 
> -- Java Information --
> Java Version:1.3.1
> Java Vendor: IBM Corporation
> Java home:   D:\cloudtst\jartest\ibm131\jre
> Java classpath:  
> D:/cloudtst/jartest/classes/derby.jar;D:/cloudtst/jartest/classes/derbytools.jar;D:/cloudtst/jartest/classes/derbynet.jar;D:/cloudtst/jartest/classes/functionTests.jar;D:/cloudtst/jartest/classes/derbyTesting.jar;D:/cloudtst/jartest/tools/java/jndi/fscontext.jar;D:/cloudtst/jartest/drda/jcc/2.4_latest/db2jcc.jar;D:/cloudtst/jartest/drda/jcc/2.4_latest/db2jcc_license_c.jar;D:/cloudtst/jartest/classes/derbyLocale_zh_TW.jar;D:/cloudtst/jartest/classes/derbyLocale_zh_CN.jar;D:/cloudtst/jartest/classes/derbyLocale_pt_BR.jar;D:/cloudtst/jartest/classes/derbyLocale_ko_KR.jar;D:/cloudtst/jartest/classes/derbyLocale_ja_JP.jar;D:/cloudtst/jartest/classes/derbyLocale_it.jar;D:/cloudtst/jartest/classes/derbyLocale_fr.jar;D:/cloudtst/jartest/classes/derbyLocale_es.jar;D:/cloudtst/jartest/classes/derbyLocale_de_DE.jar;
> OS name: Windows 2000
> OS architecture: x86
> OS version:  5.0
> Java user name:  cloudtest
> Java user home:  C:\Documents and Settings\cloudtest
> Java user dir:   
> D:\cloudtst\jartest\JarResults.2006-07-07\ibm131_derbynetmats_jcc_2.4_latest
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.3
> - Derby Information 
> JRE - JDBC: J2SE 1.3 - JDBC 2.1
> [D:\cloudtst\jartest\classes\derby.jar] 10.1.3.2 - (419765)
> [D:\cloudtst\jartest\classes\derbytools.jar] 10.1.3.2 - (419765)
> [D:\cloudtst\jartest\classes\derbynet.jar] 10.1.3.2 - (419765)
> [D:\cloudtst\jartest\drda\jcc\2.4_latest\db2jcc.jar] 2.4 - (19)
> [D:\cloudtst\jartest\drda\jcc\2.4_latest\db2jcc_license_c.jar] 2.4 - (19)
> --

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1636) document encryption of an un-encrypted database and re-encryption with new password/key.

[Suresh Thalamati (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1636?page=comments#action_12425427 ] 

Suresh Thalamati commented on DERBY-1636:
-

Refence Guide Changes:


1) New Attributes doc for re-encryption 

newEncryptionKey=  
and newBootPassword = :

above new atributes should be document under the section:
"the Setting Attributes Secttion for the Connection URL. 
http://db.apache.org/derby/docs/dev/ref/rrefattrib24612.html

Please refere to the spec for the details about these attributes. 

2) updates to the exisiting doc :

a) 
 booPassword atribute doc
 (http://db.apache.org/derby/docs/dev/ref/rrefattrib42100.html) needs to be
 updated to refelect new feature that allows configuration of a exisiting
 database for encryption. 

Modify the description Something like :

Specifies the key to use for encrypting a new database or to configure an
existing database for encryption or booting an existing encrypted database. 
Specify an alphanumeric string at least eight characters long.


In the combined attributes topic , add:

When configuring an exisiting database for encryption ,
must be combined with dataEncryption=true.

add a new example :

-- configure an existing database for encryption 
jdbc:derby:salesdb;dataEncryption=true;bootPassword=cseveryPlace



 b) dataEncryption attribute doc :
http://db.apache.org/derby/docs/dev/ref/rrefattrib15290.html
needs to be updated to reflect new feature that allows configuration 
of a exisiting database for encryption. 

some think like :

Specifies data encryption on disk for a new database or to configure an
existing database for encryption. (For information about data encryption, 
see "Encrypting Databases on Disk" in the Derby Developer's Guide.)

   In Combining with other attributes topic :
   
   remove the following sentence :
   "Must be combined with create=true:

   add a  new example :
   
   -- configure an existing database for encryption 
   jdbc:derby:salesdb;dataEncryption=true;bootPassword=cLo4u922sc23aPe


c) encryptionProvider attribute doc :
   
   In combining with other attributes topic:
   
   Remove "create=true" 
   
   i.e chane following sentence
   Must be combined with create=true, bootPassword=key, and dataEncryption=true
 
   to 
  
   Must be combined with bootPassword=key, and dataEncryption=true

   
   Add a new example :

-- configure an existing database for encryption 
jdbc:derby:salesdb;dataEncryption=true;
encryptionProvider=com.sun.crypto.provider.SunJCE;
encryptionAlgorithm=DESede/CBC/NoPadding;
bootPassword=cLo4u922sc23aPe


d) encryptionAlgorith doc (same changes as  encryption Provider):

In combining with other attributes topic:
   
   Remove "create=true" restriction:
   
   i.e change following sentence
   Must be combined with create=true, bootPassword=key, and dataEncryption=true
 
   to 
  
   Must be combined with bootPassword=key, and dataEncryption=true

   
   Add a new example :

-- configure an existing database for encryption 
jdbc:derby:salesdb;dataEncryption=true;
encryptionProvider=com.sun.crypto.provider.SunJCE;
encryptionAlgorithm=DESede/CBC/NoPadding;
bootPassword=cLo4u922sc23aPe




> document   encryption of an un-encrypted database and re-encryption with new 
> password/key.
> --
>
> Key: DERBY-1636
> URL: http://issues.apache.org/jira/browse/DERBY-1636
> Project: Derby
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 10.2.0.0
>Reporter: Suresh Thalamati
> Attachments: reencryptspec_1.html
>
>
> document   encryption of an un-encrypted database and re-encryption with new 
> password/key. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (DERBY-1637) OutBufferedStream.java fails on ibm131/jdk131 jvms.

[Sunitha Kambhampati (JIRA)]

OutBufferedStream.java fails on ibm131/jdk131 jvms.
---

 Key: DERBY-1637
 URL: http://issues.apache.org/jira/browse/DERBY-1637
 Project: Derby
  Issue Type: Bug
  Components: Regression Test Failure
Affects Versions: 10.2.0.0
 Environment: ibm131, sun jdk131 ,windows. derby jars are 10.2.0.5 
alpha - (426734)

Reporter: Sunitha Kambhampati
 Fix For: 10.2.0.0


OutBufferedStream test fails with ibm131 and jdk131. I'll attach the report 
file to this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1637) OutBufferedStream.java fails on ibm131/jdk131 jvms.

[Sunitha Kambhampati (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1637?page=all ]

Sunitha Kambhampati updated DERBY-1637:
---

Attachment: outbuffstream_derbyall_report.txt

The report file.

> OutBufferedStream.java fails on ibm131/jdk131 jvms.
> ---
>
> Key: DERBY-1637
> URL: http://issues.apache.org/jira/browse/DERBY-1637
> Project: Derby
>  Issue Type: Bug
>  Components: Regression Test Failure
>Affects Versions: 10.2.0.0
> Environment: ibm131, sun jdk131 ,windows. derby jars are 10.2.0.5 
> alpha - (426734)
>Reporter: Sunitha Kambhampati
> Fix For: 10.2.0.0
>
> Attachments: outbuffstream_derbyall_report.txt
>
>
> OutBufferedStream test fails with ibm131 and jdk131. I'll attach the report 
> file to this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Regression Test Failure! - TinderBox_Derby 428202 - Sun DBTG

[Ole . Solberg]

[Auto-generated mail]

*TinderBox_Derby* 428202/2006-08-03 02:13:41 CEST
*derbyall*

Failed  TestsOK  Skip  Duration   Platform
---
*Jvm: 1.5*
1687686 2   191.57% SunOS-5.10_i86pc-i386
  Details in  
http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-428202.html
 
  Attempted failure analysis in
  
http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/428202.html
 

Changes in  
http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/428202.txt
 

( All results in http://www.multinet.no/~solberg/public/Apache/index.html ) 

Re: Startup time for Derby

[Andrew McIntyre]

On 7/27/06, David Van Couvering <[EMAIL PROTECTED]> wrote:

I am here at OSCON and a user of Derby was complaining rather
energetically to me at the cost of startup time for Derby.  He said this
is a real problem for running unit tests, as this is compounded by
running multiple tests, each one starting up a new database.


This is something that has come up in the past and I just had a random
thought regarding this.

The structure of a new, properly shutdown database has to be static
for a specific version of Derby, right? (ok, almost, see locale note
below)  So, what if we packaged a new database in a jar file,
derbynewdb.jar, along with its exact version info, and when a
connection URL with the create attribute is passed, the engine checks
that newdb.jar is available and that the version of the newdb jar file
in the classpath is identical. If so, the engine expands the new,
empty database from the jar into the local filesystem instead of
creating all of the system tables from scratch. If the version
mismatches or the newdb.jar isn't there (or is incomplete?), we create
a new db from scratch the regular way. A new db compressed into a jar
file is only 54K for 10.2, not so bad for (re)deployment.

Someone has to have thought of this before, so I'm wondering what the
issues are here. One problem that I can think of off-hand would be
that a database is created with the JVM's current locale as the
database locale. So it would be necessary to have a way to update the
database locale after the expansion of the new db from the jar file,
maybe a system procedure that needs to be called after the expansion
of the new database from the jar. Another is what if there is a
failure while uncompressing the db, what do you do on an attempt to
reconnect? There would need to be a way to verify that you're working
with a full deck of cards, as it were, but such a verification still
seems like it would be less heavy-weight than creating a new db from
scratch.

Anyway, the idea passed through my head, so I thought I'd throw it out there...

andrew

full stack trace with JUnit?

[Andrew McIntyre]

I'm trying to track down a weird problem related to my patch for
DERBY-1424, packaging the network client code with classlister. There
is one test that is failing, jdbc4/TestConnectionMethods, and the
failure doesn't appear to be in the client code, it seems to be a test
issue, but I don't get the full exception trace so I'm not 100% sure.

Here's the output:


FAIL: failed to re-start database: Unexpected exception: java.sql.SQLException: 
java.net.ConnectException : Error connecting to server xxxFILTERED_HOSTNAMExxx 
on port 1527 with message Connection refused: connect.
java.sql.SQLException: java.net.ConnectException : Error connecting to server 
xxxFILTERED_HOSTNAMExxx on port 1527 with message Connection refused: connect.
Caused by: org.apache.derby.client.am.DisconnectException: 
java.net.ConnectException : Error connecting to server xxxFILTERED_HOSTNAMExxx 
on port 1527 with message Connection refused: connect.
... 10 more
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.Socket.(Socket.jaFAIL: isValid(0) on new connection: 
returned false
va:179)
... 16 more

Test Failed.

Is there any way to get the "10 more" or "16 more" here?

Thanks,
andrew