[jira] Commented: (DERBY-952) DerbyNet/derbynetmats/NSinSameJVM fails on Win XP / Cygwin
[ 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
[ 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
[ 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
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
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
[ 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
[ 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
[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
[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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
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
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?
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?
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
[ 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
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
[ 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?
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
[ 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?
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
[ 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
[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
*** (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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
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
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
[ 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
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
[ 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 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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
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
[ 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
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?
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
[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
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
[ 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"
[ 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
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
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
[ 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
[ 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
[ 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
[ 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
[ 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
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"
[ 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"
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[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
[ 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
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
[ 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.
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.
[ 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
[ 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.
[ 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.
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.
[ 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
[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
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?
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