Re: full stack trace with TestConnectionMethods.java
Andrew McIntyre wrote: On 8/3/06, Narayanan [EMAIL PROTECTED] wrote: Hi, SUMMARY: UNABLE TO REPRODUCE PROBLEM :-( That's a good thing. :-) I applied patch for DERBY-1424 (i.e.) derby-1424-v1.diff. /snip I also ran jdbc40 TestSuite in both the Embedded and the client frameworks. The test always seemed to pass. Seems like I am doing something wrong in my environment :-( . This is also a good thing, and thank you for trying out the patch! [snip] No Problem. Glad that I could help here :-) . Also thank you for explaining the issue you faced in the email. This would be very helpful for someone else who faces a similar problem in the future Narayanan
[jira] Commented: (DERBY-1603) ERROR 54038: Maximum depth of nested triggers was exceeded occurs when trigger fires after upating 10.1.2.5 jars to 10.1.3.1
[ http://issues.apache.org/jira/browse/DERBY-1603?page=comments#action_12426160 ] Yip Ng commented on DERBY-1603: --- Found the problem, will post the patch up for review after running some initial tests. ERROR 54038: Maximum depth of nested triggers was exceeded occurs when trigger fires after upating 10.1.2.5 jars to 10.1.3.1 -- Key: DERBY-1603 URL: http://issues.apache.org/jira/browse/DERBY-1603 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.1.3.0, 10.1.2.1, 10.1.1.0, 10.0.2.1, 10.0.2.0 Reporter: Kathey Marsden Assigned To: Yip Ng Priority: Critical Fix For: 10.2.0.0 Attachments: derby.log trigger fails after upgrading Cloudscape version 10.1.3.1 10.1 repro with the embedded driver. Execute the following in ij with version 10.1.2.5 - (409283) CREATE TABLE TEST ( TESTID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1), INFO INTEGER NOT NULL, TIMESTAMP TIMESTAMP NOT NULL DEFAULT '1980-01-01-00.00.00.00' ); CREATE TRIGGER UPDATE_TEST AFTER UPDATE ON TEST REFERENCING OLD AS OLD FOR EACH ROW MODE DB2SQL UPDATE TEST SET TIMESTAMP = CURRENT_TIMESTAMP WHERE TESTID = OLD.TESTID; INSERT INTO TEST (INFO) VALUES (1), (2), (3); Exit ij Replace derby jars with version 10.1.3.2.424154 Execute the following in ij: UPDATE TEST SET INFO = 1 WHERE TESTID = 2; ERROR 54038: Maximum depth of nested triggers was exceeded. Rajesh confirmed. I tried different combinations and found that the issue exists between versions and is present in older versions dating back to 10.0. 10.0.2.2 - (349072) database - booted in 10.1.1.0 - (208786) jars 10.1.1.0 - (208786) database - booted in 10.1.2.4 - (394241) jars 10.1.2.4 - (394241) database - booted in 10.1.2.5 - (413784) jars 10.1.2.5 - (413784) database - booted in 10.1.3.1 - (417277) jars (Attached is a derby.log that shows the stack trace using sane jars.) This (self) trigger works fine if it was created and used in the same version of jars. Below is the trace: at org.apache.derby.iapi.error.StandardException.newException(Unkno wn So urce) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext. pushT riggerExecutionContext(Unknown Source) at org.apache.derby.impl.sql.execute.InternalTriggerExecutionContex t.in it(Unknown Source) at org.apache.derby.impl.sql.execute.GenericExecutionFactory.getTri ggerE xecutionContext(Unknown Source) at org.apache.derby.impl.sql.execute.TriggerEventActivator.init (Unknow n Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.fireBeforeTrig gers( Unknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source ) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unkno wn So urce) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.execute SPS(U nknown Source) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger (Unkn own Source) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEv ent(U nknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.fireAfterTrigg ers(U nknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source ) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unkno wn So urce) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.execute SPS(U nknown Source) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger (Unkn own Source) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEv ent(U nknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.fireAfterTrigg ers(U nknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source ) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unkno wn So urce) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.execute SPS(U nknown Source) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger (Unkn own Source) at
[jira] Commented: (DERBY-1621) Trigger action statement is not recompile when there is a change that would affect it.
[ http://issues.apache.org/jira/browse/DERBY-1621?page=comments#action_12426162 ] Yip Ng commented on DERBY-1621: --- Running some initial tests on this patch as well, will post it up for review soon. While going through the SPSDescriptor implementation, I found something perplexing and need some clarifications. I'll address them on a follow up comment. Trigger action statement is not recompile when there is a change that would affect it. -- Key: DERBY-1621 URL: http://issues.apache.org/jira/browse/DERBY-1621 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.0.0 Reporter: Daniel John Debrunner Assigned To: Yip Ng Priority: Critical Fix For: 10.2.0.0 A trigger action statement, such as an INSERT statement is not recompiled when there is some DDL change on the underlying table, such as a CREATE INDEX. In the example below a unique index is added to the table (t2) inserted into by the trigger's action statement. When the tirgger fires it does not raise any error (should raise a unique constraint violated error) and does not insert the value into the index. A select from t2 does not show the additional rows in t2 as it is performing an index scan, once the index is dropped the rows appear to the select. ij version 10.2 ij connect 'jdbc:derby:cs;create=true'; ij create table t (i int); 0 rows inserted/updated/deleted ij create table t2 (i int); 0 rows inserted/updated/deleted ij create trigger tt after insert on t for each statement mode db2sql insert into t2 values 1; 0 rows inserted/updated/deleted ij insert into t values 1; 1 row inserted/updated/deleted ij select * from t2; I --- 1 1 row selected ij create unique index tu on t2(i); 0 rows inserted/updated/deleted ij insert into t values 1; 1 row inserted/updated/deleted ij select * from t2; I --- 1 1 row selected ij insert into t values 1; 1 row inserted/updated/deleted ij select * from t2; I --- 1 1 row selected ij drop index tu; 0 rows inserted/updated/deleted ij select * from t2; I --- 1 1 1 3 rows selected -- 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-939) NullPointerException at ResultSet.close() time for simple query using UNION and INTERSECT
[ http://issues.apache.org/jira/browse/DERBY-939?page=all ] Yip Ng resolved DERBY-939. -- Fix Version/s: 10.2.0.0 Resolution: Fixed 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 Fix For: 10.2.0.0 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.derby.client.net.Reply.parseLengthAndMatchCodePoint(Reply.java:1057) at org.apache.derby.client.net.NetConnectionReply.parseSQLCARD(NetConnectionReply.java:2519) at
Regression Test Failure! - Derby 429163 - Sun DBTG
[Auto-generated mail] *Derby* 429163/2006-08-06 19:46:01 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* NA NA NANA SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJDK16Jvm1.6/Limited/testSummary-429163.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJDK16Jvm1.6/429163.html *Jvm: 1.5* 2687685 2 105.21% CYGWIN_NT-5.1_i686-unknown NA NA NANA CYGWIN_NT-5.2_i686-unknown NA NA NANA Linux-2.6.14-1.1644_FC4_i686-i686 2687685 2 106.56% Linux-2.6.9-34.ELsmp_x86_64-x86_64 2687685 2 181.72% SunOS-5.10_i86pc-i386 NA NA NANA SunOS-5.10_sun4u-sparc 2687685 2 109.08% SunOS-5.11_i86pc-i386 NA NA NANA SunOS-5.9_sun4u-sparc Details in http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-429163.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/Derby/429163.html *Jvm: 1.4* NA NA NANA CYGWIN_NT-5.1_i686-unknown 2681679 4 196.07% Linux-2.6.14-1.1644_FC4_i686-i686 NA NA NANA Linux-2.6.9-34.ELsmp_x86_64-x86_64 NA NA NANA SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-429163.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJvm1.4/429163.html Changes in http://www.multinet.no/~solberg/public/Apache/Derby/UpdateInfo/429163.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Commented: (DERBY-1564) wisconsin.java test failed in DerbyNet or DerbyNetClient frameworks, VM for network server got OutOfMemoryError
[ http://issues.apache.org/jira/browse/DERBY-1564?page=comments#action_12426175 ] John H. Embretsen commented on DERBY-1564: -- This was only seen on the combination of Solaris OS and Sparc processors during 10.2.0.4 snapshot testing at Sun DBTG, and I have not seen the failure on any other platform (with default heap sizes). However, I have been focusing on trying to reproduce the failures on the specific platforms where the test failed instead of trying platforms where it did not fail, so I cannot say with very high confidence that it will never happen on other platforms. I have been able to reproduce the failure manually on some of the platforms, but only when running suites. On some platforms I have only been able to reproduce it when running derbyall, while on other platforms it has failed when running the derbynetmats or derbynetclientmats suites. On some platforms it fails in both derbyall and (one or both of) the separate suites. I have so far not been able to reproduce the failure by running the test by itself, which makes it harder to debug. It also seems that it does not fail 100% of the time on some platforms. I have been using 10.2.0.4 jars for the most part, because there has been some (unrelated) noise surrounding the wisconsin test since the snapshot was made (DERBY-1609, DERBY-1625, DERBY-1649). Also, once the patch for DERBY-1614 goes in, the test will run with different (larger) heap sizes by default, which largely reduces the risk of us seeing this failure in the near future. wisconsin.java test failed in DerbyNet or DerbyNetClient frameworks, VM for network server got OutOfMemoryError --- Key: DERBY-1564 URL: http://issues.apache.org/jira/browse/DERBY-1564 Project: Derby Issue Type: Bug Components: Network Server, Test, Regression Test Failure Affects Versions: 10.2.0.0 Environment: Solaris Sparc, Java 5 or 6, DerbyNet or DerbyNetClient framework. Reporter: Andreas Korneliussen Fix For: 10.2.0.0 Attachments: wisconsin.tar.gz The wisconsin test failed on some Solaris (sparc) platforms during testing of the 10.2.0.4 snapshot, in either the DerbyNet or DerbyNetClient framework. No output in the outfile. On some platforms the DerbyNet.err file has one message: Exception in thread Thread-2 java.lang.OutOfMemoryError: Java heap space On some platforms the OutOfMemoryError is also (or instead) reported in the derby.log file. All test machines had 2 CPUs and 2 GB of RAM. Here is a list of platforms where it failed: Java 6 (Mustang, build 91) : -- Solaris 10 (sparc) derbyall/derbynetmats/derbynetmats.fail:lang/wisconsin.java Solaris 8 (sparcN-2) derbyall/derbynetmats/derbynetmats.fail:lang/wisconsin.java Solaris 10, local zone (sparc_zone1) derbyall/derbynetmats/derbynetmats.fail:lang/wisconsin.java Solaris 10, local zone (sparc_zone3) derbynetclientmats/derbynetmats/derbynetmats.fail:lang/wisconsin.java Solaris 10, global zone (zones) derbynetmats/derbynetmats.fail:lang/wisconsin.java Java 5 (Sun's HotSpot VM, v1.5.0): --- Solaris 9 (sparcN-1) derbyall/derbynetclientmats/derbynetmats.fail:lang/wisconsin.java Solaris 8 (sparcN-2) derbyall/derbynetmats/derbynetmats.fail:lang/wisconsin.java See http://www.nabble.com/10.2.0.4-Test-results-p5485739.html for details. -- 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-1603) ERROR 54038: Maximum depth of nested triggers was exceeded occurs when trigger fires after upating 10.1.2.5 jars to 10.1.3.1
Rajesh Kartha (JIRA) wrote: I also think the title of the issue also need to change to reflect that self trigger does not throw ERROR 54038 in some cases. A few questions/concerns on this issue: 1) CORRECT TRIGGER DEFINITION: To get the semantics the user seems to want, which is to update the timestamp when TESTID changes, is this how the trigger should be defined? CREATE TRIGGER UPDATE_TEST AFTER UPDATE ON TEST REFERENCING OLD AS OLD FOR EACH ROW MODE DB2SQL UPDATE TEST SET TIMESTAMP = CURRENT_TIMESTAMP WHERE TESTID = OLD.TESTID AND OLD.TESTID != NEW.TESTID; 2) CORRECT FILING OF THE ISSUE Since the summary, and description are really wrong for this issue, I think we perhaps file a separate issue and close DERBY-1603 as invalid. I will do that. 3) USER IMPACT This one is a bit worrisome. I think the mistake made by this user would be a fairly common one and users may hit this on upgrade, but that is an existing condition. I think all we can really do is have a Release Note, mark the new issue with Existing Application Impact , and get the fix to 10.1 as soon as possible. Kathey
[jira] Created: (DERBY-1652) Update trigger updating the same rows as the original update does not throw an exception ERROR 54038: Maximum depth of nested triggers was exceeded as it should
Update trigger updating the same rows as the original update does not throw an exception ERROR 54038: Maximum depth of nested triggers was exceeded as it should --- Key: DERBY-1652 URL: http://issues.apache.org/jira/browse/DERBY-1652 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.0.2.0 Reporter: Kathey Marsden Assigned To: Yip Ng Fix For: 10.1.3.2 Execution of an update trigger that updates the same row as the original update will recurse forever and exceed the maximum nesting level of 16 so should throw the exception: ERROR 54038: Maximum depth of nested triggers was exceeded However, it does not always throw the exception. For example: CREATE TABLE TEST ( TESTID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1), INFO INTEGER NOT NULL, TIMESTAMP TIMESTAMP NOT NULL DEFAULT '1980-01-01-00.00.00.00' ); CREATE TRIGGER UPDATE_TEST AFTER UPDATE ON TEST REFERENCING OLD AS OLD FOR EACH ROW MODE DB2SQL UPDATE TEST SET TIMESTAMP = CURRENT_TIMESTAMP WHERE TESTID = OLD.TESTID; INSERT INTO TEST (INFO) VALUES (1), (2), (3); UPDATE TEST SET INFO = 1 WHERE TESTID = 2; Does not throw an exception: However, If the derby jars are updated to a new version, the correct exception is thrown. Replace derby jars with new version Execute the following in ij: UPDATE TEST SET INFO = 1 WHERE TESTID = 2; ERROR 54038: Maximum depth of nested triggers was exceeded. Note: This issue stemmed from the Invalid issue, DERBY-1603, because a user hit the exception after upgrade and thought the exception after upgrade, not the lack of exception before upgrade was the problem. This may be a common user error, so we need a release note to help mitigate the issue.I will add one shortly after confirming the correct trigger syntax. -- 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-1603) ERROR 54038: Maximum depth of nested triggers was exceeded occurs when trigger fires after upating 10.1.2.5 jars to 10.1.3.1
[ http://issues.apache.org/jira/browse/DERBY-1603?page=all ] Kathey Marsden resolved DERBY-1603. --- Resolution: Invalid This issue is being closed as invalid and a new issue DERBY-1652 filed with the correct description. The actual problem is that the exception is not being thrown before upgrade. ERROR 54038: Maximum depth of nested triggers was exceeded occurs when trigger fires after upating 10.1.2.5 jars to 10.1.3.1 -- Key: DERBY-1603 URL: http://issues.apache.org/jira/browse/DERBY-1603 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.1.3.0, 10.1.2.1, 10.1.1.0, 10.0.2.1, 10.0.2.0 Reporter: Kathey Marsden Assigned To: Yip Ng Priority: Critical Fix For: 10.2.0.0 Attachments: derby.log trigger fails after upgrading Cloudscape version 10.1.3.1 10.1 repro with the embedded driver. Execute the following in ij with version 10.1.2.5 - (409283) CREATE TABLE TEST ( TESTID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1), INFO INTEGER NOT NULL, TIMESTAMP TIMESTAMP NOT NULL DEFAULT '1980-01-01-00.00.00.00' ); CREATE TRIGGER UPDATE_TEST AFTER UPDATE ON TEST REFERENCING OLD AS OLD FOR EACH ROW MODE DB2SQL UPDATE TEST SET TIMESTAMP = CURRENT_TIMESTAMP WHERE TESTID = OLD.TESTID; INSERT INTO TEST (INFO) VALUES (1), (2), (3); Exit ij Replace derby jars with version 10.1.3.2.424154 Execute the following in ij: UPDATE TEST SET INFO = 1 WHERE TESTID = 2; ERROR 54038: Maximum depth of nested triggers was exceeded. Rajesh confirmed. I tried different combinations and found that the issue exists between versions and is present in older versions dating back to 10.0. 10.0.2.2 - (349072) database - booted in 10.1.1.0 - (208786) jars 10.1.1.0 - (208786) database - booted in 10.1.2.4 - (394241) jars 10.1.2.4 - (394241) database - booted in 10.1.2.5 - (413784) jars 10.1.2.5 - (413784) database - booted in 10.1.3.1 - (417277) jars (Attached is a derby.log that shows the stack trace using sane jars.) This (self) trigger works fine if it was created and used in the same version of jars. Below is the trace: at org.apache.derby.iapi.error.StandardException.newException(Unkno wn So urce) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext. pushT riggerExecutionContext(Unknown Source) at org.apache.derby.impl.sql.execute.InternalTriggerExecutionContex t.in it(Unknown Source) at org.apache.derby.impl.sql.execute.GenericExecutionFactory.getTri ggerE xecutionContext(Unknown Source) at org.apache.derby.impl.sql.execute.TriggerEventActivator.init (Unknow n Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.fireBeforeTrig gers( Unknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source ) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unkno wn So urce) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.execute SPS(U nknown Source) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger (Unkn own Source) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEv ent(U nknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.fireAfterTrigg ers(U nknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source ) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unkno wn So urce) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.execute SPS(U nknown Source) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger (Unkn own Source) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEv ent(U nknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.fireAfterTrigg ers(U nknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source ) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unkno wn So urce) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.execute SPS(U nknown Source) at
[jira] Commented: (DERBY-1637) OutBufferedStream.java fails on ibm131/jdk131 jvms.
[ http://issues.apache.org/jira/browse/DERBY-1637?page=comments#action_12426221 ] Tomohito Nakayama commented on DERBY-1637: -- I confirmed to execute derbynet/OutBufferedStream.java with derby1637.draft.txt and found it passes in my development environment. 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: 1637_jcc2.4.zip, derby1637.draft.txt, javacore.20060804.101637.3308.txt, javacore.20060804.101643.3308.txt, outbuff_ibm131.jar, 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
[jira] Commented: (DERBY-1029) Backout boolean work from the 10.2 branch immediately after the branch is created
[ http://issues.apache.org/jira/browse/DERBY-1029?page=comments#action_12426223 ] Rick Hillegas commented on DERBY-1029: -- Thanks for tripping across this, Kristian. I have deleted the directory of empty files (lang) with subversion revision 429350. Backout boolean work from the 10.2 branch immediately after the branch is created - Key: DERBY-1029 URL: http://issues.apache.org/jira/browse/DERBY-1029 Project: Derby Issue Type: Sub-task Components: SQL Affects Versions: 10.2.0.0 Reporter: Kathey Marsden Assigned To: Rick Hillegas Priority: Blocker Fix For: 10.2.0.0 Attachments: derby-1029_v03.diff, derby-1029_v05.diff There was discussion on the list regarding how to handle this issue but keep the BOOLEAN work for inclusion in future releases. The approach discussed was to back the DERBY-499 work out of the 10.2 branch as soon as it is created, but leave it in the trunk I think this an acceptable solution but only if we can get someone assigned to this issue that is willing to commit now to doing that work as soon as we branch. The reverse merge may be messy at that point do to other changes that have gone in. Is there someone who will volunteer to do this work and assign themselves 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-1639) Include early-draft notice required by JDBC 4 spec license in NOTICES, release notes and documentation
[ http://issues.apache.org/jira/browse/DERBY-1639?page=all ] Rick Hillegas updated DERBY-1639: - Derby Info: [Release Note Needed] (was: [Patch Available, Release Note Needed]) Lowering the patch available flag until this issue settles. Include early-draft notice required by JDBC 4 spec license in NOTICES, release notes and documentation -- Key: DERBY-1639 URL: http://issues.apache.org/jira/browse/DERBY-1639 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.0.0 Reporter: Andrew McIntyre Assigned To: Rick Hillegas Fix For: 10.2.0.0 Attachments: derby-1639-notice_v01.diff, derby-1639-notice_v02.diff from the license: 3. Distribute applications written to the Specification to third parties for their testing and evaluation use, provided that any such application includes the following notice: This is an application written to interoperate with an early-draft specification developed under the Java Community Process (JCP) and is made available for testing and evaluation purposes only. The code is not compatible with any specification of the JCP. This notice needs to be included in the NOTICES file, and should also be used to frame discussion of JDBC 4.0 features in the release notes and documentation. Here is a RELEASE NOTE for inclusion with this issue. I am editting this note into the Description field so that we can amend it if necessary: - RELEASE NOTE PROBLEM: Derby 10.2 exposes an implementation of an early draft version of the JDBC4 specification. SYMPTOM: This issue only affects you if you are running the Derby network client or embedded server on Java SE 6. This issue does not affect you if you are running Derby on J2SE 1.3, 1.4, or 1.5. When run on Java SE 6, Derby's network client and embedded server expose JDBC implementations which do not conform to an approved, final version of the JDBC specification. Instead, these implementations adhere to an early-draft version of the JDBC4 specification. Please note the following: This is an application written to interoperate with an early-draft specification developed under the Java Community Process (JCP) and is made available for testing and evaluation purposes only. The code is not compatible with any specification of the JCP. SOLUTION: A follow-on release will expose JDBC4 implementations conforming to the final draft of the JDBC4 specification. WORKAROUND: If you do not want to use experimental, early-draft JDBC4 interfaces, run Derby on J2SE 1.3, 1.4, or 1.5 or on J2ME/CDC/Foundation 1.0. -- 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-1652) Update trigger updating the same rows as the original update does not throw an exception ERROR 54038: Maximum depth of nested triggers was exceeded as it should
[ http://issues.apache.org/jira/browse/DERBY-1652?page=comments#action_12426232 ] Daniel John Debrunner commented on DERBY-1652: -- Does the comment However, If the derby jars are updated to a new version mean that the bug is fixed in the new version and so thiis bug is already fixed. Ie. it is just a problem with some older versions and upgrading to the latest 10.1 will mean the exception is always thrown, no matter how the trigger was created? Update trigger updating the same rows as the original update does not throw an exception ERROR 54038: Maximum depth of nested triggers was exceeded as it should --- Key: DERBY-1652 URL: http://issues.apache.org/jira/browse/DERBY-1652 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.0.2.0 Reporter: Kathey Marsden Assigned To: Yip Ng Fix For: 10.1.3.2 Execution of an update trigger that updates the same row as the original update will recurse forever and exceed the maximum nesting level of 16 so should throw the exception: ERROR 54038: Maximum depth of nested triggers was exceeded However, it does not always throw the exception. For example: CREATE TABLE TEST ( TESTID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1), INFO INTEGER NOT NULL, TIMESTAMP TIMESTAMP NOT NULL DEFAULT '1980-01-01-00.00.00.00' ); CREATE TRIGGER UPDATE_TEST AFTER UPDATE ON TEST REFERENCING OLD AS OLD FOR EACH ROW MODE DB2SQL UPDATE TEST SET TIMESTAMP = CURRENT_TIMESTAMP WHERE TESTID = OLD.TESTID; INSERT INTO TEST (INFO) VALUES (1), (2), (3); UPDATE TEST SET INFO = 1 WHERE TESTID = 2; Does not throw an exception: However, If the derby jars are updated to a new version, the correct exception is thrown. Replace derby jars with new version Execute the following in ij: UPDATE TEST SET INFO = 1 WHERE TESTID = 2; ERROR 54038: Maximum depth of nested triggers was exceeded. Note: This issue stemmed from the Invalid issue, DERBY-1603, because a user hit the exception after upgrade and thought the exception after upgrade, not the lack of exception before upgrade was the problem. This may be a common user error, so we need a release note to help mitigate the issue.I will add one shortly after confirming the correct trigger syntax. -- 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-694) Statement exceptions cause all the connection's result sets to be closed with the client driver
[ http://issues.apache.org/jira/browse/DERBY-694?page=all ] V.Narayanan updated DERBY-694: -- Attachment: DERBY-694_v4.diff DERBY-694_v4.stat I was earlier checking for the severity of the exception by, netSqlca.getSqlCode() ExceptionSeverity.STATEMENT_SEVERITY I realized that a better way of doing this would be ExceptionUtil.getSeverityFromIdentifier(netSqlca.getSqlState()) ExceptionSeverity.STATEMENT_SEVERITY I can get the SQLState of the exception from netSqlca.getSqlState(). I understood the NetSqlca class as holding the values of the parsing of SQLCA obtained from a ABNUOWRM. The severity of this exception can be derived using the method ExceptionUtil.getSeverityFromIdentifier. This can then be used to ensure that the severity of the exception is lesser than STATEMENT_SEVERITY. I have modified my patch to do this. I am submitting the same. What I not been able to do is to generate an ABNUOWRM with a severity STATEMENT_SEVERITY. I will however submit a patch testing the case pointed out in this issue after running derbyall by tomorrow. thanx Narayanan Statement exceptions cause all the connection's result sets to be closed with the client driver --- Key: DERBY-694 URL: http://issues.apache.org/jira/browse/DERBY-694 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.1.1.1 Reporter: Oyvind Bakksjo Assigned To: V.Narayanan Priority: Minor Attachments: DERBY-694.html, DERBY-694_upload_v1.diff, DERBY-694_upload_v1.stat, DERBY-694_v2.diff, DERBY-694_v2.stat, DERBY-694_v3.diff, DERBY-694_v3.stat, DERBY-694_v4.diff, DERBY-694_v4.stat, StatementRollbackTest.java Scenario: Autocommit off. Have two prepared statements, calling executeQuery() on both, giving me two result sets. Can fetch data from both with next(). If one statement gets an exception (say, caused by a division by zero), not only this statement's result set is closed, but also the other open resultset. This happens with the client driver, whereas in embedded mode, the other result set is unaffected by the exception in the first result set (as it should be). -- 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-1637) OutBufferedStream.java fails on ibm131/jdk131 jvms.
[ http://issues.apache.org/jira/browse/DERBY-1637?page=comments#action_12426235 ] Tomohito Nakayama commented on DERBY-1637: -- I meant ibm131 on Linux... 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: 1637_jcc2.4.zip, derby1637.draft.txt, javacore.20060804.101637.3308.txt, javacore.20060804.101643.3308.txt, outbuff_ibm131.jar, 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
[jira] Commented: (DERBY-1554) IDENTITY_VAL_LOCAL() returned value is modified incorrectly by a multi-row INSERT statement.
[ http://issues.apache.org/jira/browse/DERBY-1554?page=comments#action_12426239 ] Rick Hillegas commented on DERBY-1554: -- Thanks, Yip. The edits look good to me. As a sanity check, I'm running derbyall on my linux machine. Will commit if the tests run fine. IDENTITY_VAL_LOCAL() returned value is modified incorrectly by a multi-row INSERT statement. Key: DERBY-1554 URL: http://issues.apache.org/jira/browse/DERBY-1554 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.0.0 Reporter: Daniel John Debrunner Assigned To: Yip Ng Fix For: 10.2.0.0 Attachments: DERBY-1554.diff, DERBY-1554.stat, derby1554trunkdiff01.txt, derby1554trunkdiff02.txt, derby1554trunkstat01.txt, derby1554trunkstat02.txt Changes made in DERBY-353 break the documented behaviour of IDENTITY_VAL_LOCAL(). Now the returned value is modified when a multi-row insert is performed. IDENTITY_VAL_LOCAL() should not be updated when this occurs. For this script the last value returned should be 2 (as in 10.1) but in 10.2 is 4 create table ta (a int, b int generated always as identity); insert into ta(a) values 100; values IDENTITY_VAL_LOCAL(); insert into ta(a) values 200; values IDENTITY_VAL_LOCAL(); insert into ta(a) values 300,400; values IDENTITY_VAL_LOCAL(); -- 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-1652) Update trigger updating the same rows as the original update does not throw an exception ERROR 54038: Maximum depth of nested triggers was exceeded as it should
[ http://issues.apache.org/jira/browse/DERBY-1652?page=comments#action_12426240 ] Kathey Marsden commented on DERBY-1652: --- Dan asked: Does the comment However, If the derby jars are updated to a new version mean that the bug is fixed in the new version and so thiis bug is already fixed. No if you create this trigger in the latest 10.2 you will see that when it fires it does not give an exception. It is changing versions that triggers the trigger to start giving the exception. So for instance if you create the trigger in 10.1.3.1, it would fire without error until you moved to 10.1.3.2. Then you would start seeing the exception when the trigger fires. This is why I am concerned about user impact with this issue. The incorrect trigger will operate as the user might think it would until they upgrade and then boom, their application works no more. Update trigger updating the same rows as the original update does not throw an exception ERROR 54038: Maximum depth of nested triggers was exceeded as it should --- Key: DERBY-1652 URL: http://issues.apache.org/jira/browse/DERBY-1652 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.0.2.0 Reporter: Kathey Marsden Assigned To: Yip Ng Fix For: 10.1.3.2 Execution of an update trigger that updates the same row as the original update will recurse forever and exceed the maximum nesting level of 16 so should throw the exception: ERROR 54038: Maximum depth of nested triggers was exceeded However, it does not always throw the exception. For example: CREATE TABLE TEST ( TESTID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1), INFO INTEGER NOT NULL, TIMESTAMP TIMESTAMP NOT NULL DEFAULT '1980-01-01-00.00.00.00' ); CREATE TRIGGER UPDATE_TEST AFTER UPDATE ON TEST REFERENCING OLD AS OLD FOR EACH ROW MODE DB2SQL UPDATE TEST SET TIMESTAMP = CURRENT_TIMESTAMP WHERE TESTID = OLD.TESTID; INSERT INTO TEST (INFO) VALUES (1), (2), (3); UPDATE TEST SET INFO = 1 WHERE TESTID = 2; Does not throw an exception: However, If the derby jars are updated to a new version, the correct exception is thrown. Replace derby jars with new version Execute the following in ij: UPDATE TEST SET INFO = 1 WHERE TESTID = 2; ERROR 54038: Maximum depth of nested triggers was exceeded. Note: This issue stemmed from the Invalid issue, DERBY-1603, because a user hit the exception after upgrade and thought the exception after upgrade, not the lack of exception before upgrade was the problem. This may be a common user error, so we need a release note to help mitigate the issue.I will add one shortly after confirming the correct trigger syntax. -- 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-1603) ERROR 54038: Maximum depth of nested triggers was exceeded occurs when trigger fires after upating 10.1.2.5 jars to 10.1.3.1
Kathey Marsden wrote: A few questions/concerns on this issue: 1) CORRECT TRIGGER DEFINITION: To get the semantics the user seems to want, which is to update the timestamp when TESTID changes, is this how the trigger should be defined? [snip wrong syntax] Answer is no. Not sure why I thought I saw this work before. Playing with it now, it does not. Kathey
10.2 patches available for review
The 10.2 wiki page (http://wiki.apache.org/db-derby/TenTwoRelease), in its Bug Fix Candidates section now contains a link to all open/reopened issues which are targetted for 10.2 and which have raised their patch available flags. Regards, -Rick
Re: [jira] Commented: (DERBY-1603) ERROR 54038: Maximum depth of nested triggers was exceeded occurs when trigger fires after upating 10.1.2.5 jars to 10.1.3.1
Kathey Marsden wrote: Kathey Marsden wrote: A few questions/concerns on this issue: 1) CORRECT TRIGGER DEFINITION: I think this is it. To update the timestamp when info is updated we do this: with 10.1.2.4 ij version 10.1 ij connect 'jdbc:derby:wombat;create=true'; ij CREATE TABLE TEST ( TESTID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1), INFO INTEGER NOT NULL, TIMESTAMP TIMESTAMP NOT NULL DEFAULT '1980-01-01-00.00.00.00' ); 0 rows inserted/updated/deleted ij CREATE TRIGGER UPDATE_TEST AFTER UPDATE ON TEST REFERENCING OLD AS OLD FOR EACH ROW MODE DB2SQL UPDATE TEST SET TIMESTAMP = CURRENT_TIMESTAMP WHERE TESTID = OLD.TESTID AND INFO != OLD.INFO ; 0 rows inserted/updated/deleted ij INSERT INTO TEST (INFO) VALUES (1), (2), (3); 3 rows inserted/updated/deleted ij UPDATE TEST SET INFO = 1 WHERE TESTID = 2; 1 row inserted/updated/deleted with 10.1.2.5 ... ij ij version 10.1 ij connect 'jdbc:derby:wombat'; ij UPDATE TEST SET INFO = 1 WHERE TESTID = 2; 1 row inserted/updated/deleted ij SELECT * FROM TEST; TESTID |INFO |TIMESTAMP -- 1 |1 |1980-01-01 00:00:00.0 2 |1 |2006-08-07 08:08:32.958 3 |3 |1980-01-01 00:00:00.0 3 rows selected
[jira] Commented: (DERBY-1640) Instability in XATest
[ http://issues.apache.org/jira/browse/DERBY-1640?page=comments#action_12426254 ] Rick Hillegas commented on DERBY-1640: -- Committed at subversion revision 429365. Instability in XATest - Key: DERBY-1640 URL: http://issues.apache.org/jira/browse/DERBY-1640 Project: Derby Issue Type: Bug Components: Test, Regression Test Failure Affects Versions: 10.2.0.0 Reporter: Rick Hillegas Assigned To: Yip Ng Fix For: 10.2.0.0 Attachments: derby1640trunkdiff01.txt, derby1640trunkstat01.txt I am seeing the following diff in XATest, in a clean subversion client running under DerbyNetClient framework on jdk14 on either Linux or cygwin/xp: 52a53 (1 |PREPARED |false |APP |UserTransaction 54d54 (1 |PREPARED |false |APP |UserTransaction Test Failed. *** End: XATest jdk1.4.2_08 DerbyNetClient 2006-08-03 13:06:22 *** Looks like an ordering instability. -- 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-1640) Instability in XATest
[ http://issues.apache.org/jira/browse/DERBY-1640?page=all ] Rick Hillegas updated DERBY-1640: - Derby Info: (was: [Patch Available]) Instability in XATest - Key: DERBY-1640 URL: http://issues.apache.org/jira/browse/DERBY-1640 Project: Derby Issue Type: Bug Components: Test, Regression Test Failure Affects Versions: 10.2.0.0 Reporter: Rick Hillegas Assigned To: Yip Ng Fix For: 10.2.0.0 Attachments: derby1640trunkdiff01.txt, derby1640trunkstat01.txt I am seeing the following diff in XATest, in a clean subversion client running under DerbyNetClient framework on jdk14 on either Linux or cygwin/xp: 52a53 (1 |PREPARED |false |APP |UserTransaction 54d54 (1 |PREPARED |false |APP |UserTransaction Test Failed. *** End: XATest jdk1.4.2_08 DerbyNetClient 2006-08-03 13:06:22 *** Looks like an ordering instability. -- 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-1603) ERROR 54038: Maximum depth of nested triggers was exceeded occurs when trigger fires after upating 10.1.2.5 jars to 10.1.3.1
Kathey Marsden wrote: Kathey Marsden wrote: Kathey Marsden wrote: A few questions/concerns on this issue: 1) CORRECT TRIGGER DEFINITION: I think this is it. To update the timestamp when info is updated we do this: 0 rows inserted/updated/deleted ij CREATE TRIGGER UPDATE_TEST AFTER UPDATE ON TEST REFERENCING OLD AS OLD FOR EACH ROW MODE DB2SQL UPDATE TEST SET TIMESTAMP = CURRENT_TIMESTAMP WHERE TESTID = OLD.TESTID AND INFO != OLD.INFO ; 0 rows inserted/updated/deleted The trigger can also be defined to only fire on update of certain columns, e.g. AFTER UPDATE ON TEST(INFO) Then I think this would lead to a simpler action statement of UPDATE TEST SET TIMESTAMP = CURRENT_TIMESTAMP WHERE TESTID = OLD.TESTID A statement trigger might be best in this case, would result in a single update statement rather than N. Dan.
[jira] Commented: (DERBY-694) Statement exceptions cause all the connection's result sets to be closed with the client driver
[ http://issues.apache.org/jira/browse/DERBY-694?page=comments#action_12426256 ] V.Narayanan commented on DERBY-694: --- Doing a getSqlCode() on NetSqlCa in the above case was returning a -1. This value is less than ExceptionSeverity.STATEMENT_SEVERITY(2) hence it was passing in my previous patch. I did not however have a way of ever deciding on this as the right method to check for exception severity. (I would have needed to generate a ABNUOWRM with severity STATEMENT_SEVERITY) My only lifeline in this case was through the following cutting and pasting from the comments above c.1) I inferred that the getSqlCode() contains the severity information from the code for SqlExceptionFactory40 where in the getSQLException method we check for errCode = ExceptionSeverity.SESSION_SEVERITY. c.2) This method is called from SqlException.getSQLException() which in turn passes to this as parameter return value of getErrorCode(). c.3) getErrorCode() inturn obtains the error code from sqlca_.getSqlCode() when sqlca_ is not null. To test the above inference I needed a way of generating an ABNUOWRM with severity greater than STATEMENT_SEVERITY becase in this case getSqlCode() cannot be -1. But I wasn't able to generate this case. I have already mentioned this in the above comments. NetSqlCa.getSqlState() on the other hand does not return me a default value like -1 but returns 22012 from which the severity is derived. So I can be sure that getSqlState does return me a valid value from which I can call the ExceptionUtil methods to derive severity . I did'nt feel safe sticking to the getSqlCode way which is based on an inference and a test that passes because a default value of getSqlCode is lesser than severity value. Hence I decided to stick to the getSqlState method. If there is someone who can guide me into generating a test case that can generate a ABNUOWRM with severity STATEMENT_SEVERITY I most humbly request for guidance from them. thanx Narayanan Statement exceptions cause all the connection's result sets to be closed with the client driver --- Key: DERBY-694 URL: http://issues.apache.org/jira/browse/DERBY-694 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.1.1.1 Reporter: Oyvind Bakksjo Assigned To: V.Narayanan Priority: Minor Attachments: DERBY-694.html, DERBY-694_upload_v1.diff, DERBY-694_upload_v1.stat, DERBY-694_v2.diff, DERBY-694_v2.stat, DERBY-694_v3.diff, DERBY-694_v3.stat, DERBY-694_v4.diff, DERBY-694_v4.stat, StatementRollbackTest.java Scenario: Autocommit off. Have two prepared statements, calling executeQuery() on both, giving me two result sets. Can fetch data from both with next(). If one statement gets an exception (say, caused by a division by zero), not only this statement's result set is closed, but also the other open resultset. This happens with the client driver, whereas in embedded mode, the other result set is unaffected by the exception in the first result set (as it should be). -- 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] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (18 issues) Subscriber: derby-dev Key Summary DERBY-1554 IDENTITY_VAL_LOCAL() returned value is modified incorrectly by a multi-row INSERT statement. http://issues.apache.org/jira/browse/DERBY-1554 DERBY-1533 ArrayIndexOutOfBoundsException in DDMReader, on a specific data size http://issues.apache.org/jira/browse/DERBY-1533 DERBY-688 Enhancements to XML functionality to move toward XPath/XQuery support... http://issues.apache.org/jira/browse/DERBY-688 DERBY-1516 Inconsistent behavior for getBytes and getSubString for embedded versus network http://issues.apache.org/jira/browse/DERBY-1516 DERBY-1614 Test harness overrides heap size settings when starting Network Server http://issues.apache.org/jira/browse/DERBY-1614 DERBY-1032 Create new scripts which follow common practice at Apache http://issues.apache.org/jira/browse/DERBY-1032 DERBY-1320 Test lang/procedure.java fails with ibm1.5 jvm http://issues.apache.org/jira/browse/DERBY-1320 DERBY-1431 Typo in link to Simple Example from frameworks/readme.html http://issues.apache.org/jira/browse/DERBY-1431 DERBY-244 with linux, depending on env setting $LANG and console encoding, some i18n tests fail http://issues.apache.org/jira/browse/DERBY-244 DERBY-1539 As per the functional spec attached to DERBY-1330, a trigger should be dropped when a privilege required by the trigger is revoked. http://issues.apache.org/jira/browse/DERBY-1539 DERBY-801 Allow parallel access to data files. http://issues.apache.org/jira/browse/DERBY-801 DERBY-815 Prevent unneeded object creation and excessive decoding in parseSQLDTA_work() http://issues.apache.org/jira/browse/DERBY-815 DERBY-1574 NullPointerException in UPDATE with COALESCE and subquery http://issues.apache.org/jira/browse/DERBY-1574 DERBY-883 Enhance GROUP BY clause to support expressions instead of just column references. http://issues.apache.org/jira/browse/DERBY-883 DERBY-402 INTERSECT/EXCEPT/UNION operators don't agree with documented behavior. http://issues.apache.org/jira/browse/DERBY-402 DERBY-1194 Derby Server and Administration Guide - Managing the Derby Network Server http://issues.apache.org/jira/browse/DERBY-1194 DERBY-1399 DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver autoloading http://issues.apache.org/jira/browse/DERBY-1399 DERBY-1389 IS_AUTOINCREMENT column should be returned as part of the Database description returned by DatabaseMetaData.getColumns http://issues.apache.org/jira/browse/DERBY-1389
[jira] Updated: (DERBY-1643) As per the functional spec attached to DERBY-1330, a revoke execute ... restrict should fail if there are dependent objects on the execute privilege
[ http://issues.apache.org/jira/browse/DERBY-1643?page=all ] Mamta A. Satoor updated DERBY-1643: --- Derby Info: [Patch Available] As per the functional spec attached to DERBY-1330, a revoke execute ... restrict should fail if there are dependent objects on the execute privilege -- Key: DERBY-1643 URL: http://issues.apache.org/jira/browse/DERBY-1643 Project: Derby Issue Type: New Feature Components: SQL Affects Versions: 10.2.0.0 Reporter: Mamta A. Satoor Assigned To: Mamta A. Satoor Attachments: DERBY1643_diff_V1_RevokeExecutePrivilege.txt, DERBY1643_diff_V2_RevokeExecutePrivilege.txt, DERBY1643_stat_V1_RevokeExecutePrivilege.txt, DERBY1643_stat_V2_RevokeExecutePrivilege.txt As per the functional spec attached to DERBY-1330, a revoke execute ... restrict should fail if there are dependent objects on the execute privilege In order to implement this, when revoke execute is executed, a special invalidation action should be sent and dependent objects will need to catch that invalidation and throw an exception. If there are no dependents, then no exception will be thrown and revoke execute will succeed. I am just creating a new jira entry here so it is easier to track sub items of DERBY-1330. Will link this Jira entry to DERBY-1330. -- 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-1597) Scripts in frameworks direcotry needs to be revisted to set up CLASSPATH properly
[ http://issues.apache.org/jira/browse/DERBY-1597?page=all ]
Ramandeep Kaur updated DERBY-1597:
--
Attachment: DERBY-1597.diff
Submitting patch for DERBY-1597. Please review it.
Scripts in frameworks direcotry needs to be revisted to set up CLASSPATH
properly
-
Key: DERBY-1597
URL: http://issues.apache.org/jira/browse/DERBY-1597
Project: Derby
Issue Type: Bug
Components: Demos/Scripts
Affects Versions: 10.2.0.0
Reporter: Ramandeep Kaur
Assigned To: Andrew McIntyre
Attachments: DERBY-1597.diff
Need to revisit scripts in directory frameworks/embedded/bin and
frameworks/NetworkServer/bin for setting up CLASSPATH properly. The current
problem is as following:
If user already has a CLASSPATH set on their system, the CLASSPATH is not set
again within the script. Therefore, there are no derby classes in the
CLASSPATH which results in java command failing as it can not find the derby
class it is calling. Basically, to make the scripts work, user has to either
issue command set CLASSPATH= or have derby jar files be appended to their
system CLASSPATH before running any frameworks batch script.
In ksh scripts, there is same problem except that the user has to issue
command export CLASSPATH= or have derby jar files be appended to their
system CLASSPATH only once as whatever CLASSPATH is set up by scripts is not
visible once the script is done.
So I am proposing the following solution so that frameworks scripts work
properly without interfering with system classpath or without any setup from
user.
In batch scripts:-
--
1. Before line call
%DERBY_INSTALL%/frameworks/embedded/bin/setEmbeddedCP.bat, save the
current classpath as follows:
set SAVED_CLASSPATH=%CLASSPATH%
2. Replace the following lines:
@if !%CLASSPATH%==! call
%DERBY_INSTALL%/frameworks/embedded/bin/setEmbeddedCP.bat
@if %CLASSPATH% == call
%DERBY_INSTALL%/frameworks/embedded/bin/setEmbeddedCP.bat
with
call %DERBY_INSTALL%/frameworks/embedded/bin/setEmbeddedCP.bat
Note: I have given the above as example only. The name of script that is
getting called may be different.
3. At the end of script, reset the CLASSPATH to system CLASSPATH as follows:
set CLASSPATH=%SAVED_CLASSPATH%
In korn scripts:-
--
In ksh script, even though system classpath is only modified within the
script and is not effective once script exits, to be consistent with batch
scripts, do the following:
1. Before line . $DERBY_HOME/frameworks/embedded/bin/setEmbeddedCP.ksh
save the current classpath as follows:
export SAVED_CLASSPATH=$CLASSPATH
2. Replace the following lines:
[ -z $CLASSPATH ] {
. $DERBY_HOME/frameworks/embedded/bin/setEmbeddedCP.ksh
}
with
. $DERBY_HOME/frameworks/embedded/bin/setEmbeddedCP.ksh
Note: I have given the above as example only. The name of script that is
getting called may be different.
3. At the end of script, reset the CLASSPATH to system CLASSPATH as follows:
export CLASSPATH=$SAVED_CLASSPATH
--
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-1377) Update copyright headers to comply with new ASF policy
I wouldn't mind the delay. Let us know what answer comes around on this one. Daniel John Debrunner (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1377?page=comments#action_12425969 ] Daniel John Debrunner commented on DERBY-1377: -- FYI Geir Magnusson Jr asked on legal-discuss if the deadline of 9/1 for this could be extended to account for the fact that it's summer vacation season in the northern hemisphere. While I think we want to make progress on this, not having to do it all for 10.2 might be a relief. And seeing how much work it is (thanks to david for the wiki page), it seems like a future bug fix release on 10.1 is very unlikely, which is a shame. Update copyright headers to comply with new ASF policy -- Key: DERBY-1377 URL: http://issues.apache.org/jira/browse/DERBY-1377 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.0.0 Reporter: Jean T. Anderson Assigned To: David Van Couvering Fix For: 10.2.0.0 Attachments: DERBY-1377_NOTICE_diff.txt A new copyright header policy will take effect for distributions released starting on Sep 1, 2006. Committers will receive notification, but a heads up with details is in the legal-discuss thread starting with http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL PROTECTED] Date was 1-Aug-2006, is now 1-Sep-2006: http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200607.mbox/[EMAIL PROTECTED]
[jira] Updated: (DERBY-1470) Correct instructions in demo html file demo\simple\example.html
[ http://issues.apache.org/jira/browse/DERBY-1470?page=all ]
Ramandeep Kaur updated DERBY-1470:
--
Attachment: DERBY-1470.diff
Submitting diffs. Please review it.
Correct instructions in demo html file demo\simple\example.html
---
Key: DERBY-1470
URL: http://issues.apache.org/jira/browse/DERBY-1470
Project: Derby
Issue Type: Bug
Components: Demos/Scripts
Affects Versions: 10.2.0.0, 10.1.3.1
Environment: Any platform on which we support derby
Reporter: Ramandeep Kaur
Assigned To: Ramandeep Kaur
Priority: Minor
Fix For: 10.2.0.0
Attachments: DERBY-1470.diff
In file demo\simple\example.html, under section Next run the SimpleApp demo
in Derby client mode:, step 5
java org.apache.derby.tools.sysinfo -cp client SimpleApp.class gives the
following error:
Exception in thread main java.lang.NoClassDefFoundError:
org/apache/derby/tools/sysinfo
The above error is given because step 4 instructs to set path as following:
export CLASSPATH=.:${DERBY_INSTALL}/lib/derbyclient.jar
Now as neither derby.jar or derbytool.jar is been added to the above
classpath, sysinfo file not found.
Step 4 should instruct to set up path as following:
export
CLASSPATH=.:${DERBY_INSTALL}/lib/derbyclient.jar:${DERBY_INSTALL}/lib/derby.jar
--
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-1603) ERROR 54038: Maximum depth of nested triggers was exceeded occurs when trigger fires after upating 10.1.2.5 jars to 10.1.3.1
Daniel John Debrunner wrote: Then I think this would lead to a simpler action statement of UPDATE TEST SET TIMESTAMP = CURRENT_TIMESTAMP WHERE TESTID = OLD.TESTID A statement trigger might be best in this case, would result in a single update statement rather than N. Hmmm Well, this (I think) is where we started and from what I understand from Yip is the case that is always supposed to give us the Maximum depth of nested triggers was exceeded error (DERBY-1652). If the trigger is defined this way, when the row is updated, it fires the update trigger which updates the row which fires the update trigger etc... I added the additional qualifier ( AND INFO != OLD.INFO to make it stop on the second fire. Is there a better way? Kathey
Code coverage results for trunk svn no 428586
Hi All, I ran code coverage for trunk - svn revision no428586 with sun jdk131, sun jdk142, sun jdk15, and sun jdk16on Windows 2000, and results are as following:- OVERALL COVERAGE SUMMARY Classes: 93% (1177/1260) Methods: 78% (16331/20921) Blocks: 75% (490643/658117) Lines: 75% (101611.2/136333) OVERALL STATS SUMMARY total packages: 79 total executable files: 1195 total classes: 1260 total methods: 20921 total executable lines: 136333 -- Ramandeep Kaur[EMAIL PROTECTED]
[jira] Updated: (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=all ] Laura Stewart updated DERBY-1548: - Attachment: derby1548_ref2.diff derby1548_ref_html2.zip Updated the text based on the comments received. Attached an updated zip file which contains html copies of the files and a diff file. Please review and commit this patch. Laura 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: derby1548_ref.diff, derby1548_ref2.diff, derby1548_ref_html.zip, derby1548_ref_html2.zip, 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-1549) Document support for JDBC escape functions: ACOS, ASIN, ATAN, COS, SIN, TAN, PI , DEGREES, RADIANS, EXP, LOG, LOG10, CEILING, FLOOR
[ http://issues.apache.org/jira/browse/DERBY-1549?page=comments#action_12426270 ] Laura Stewart commented on DERBY-1549: -- Please review and answer the question that I posted on 8/3. Document support for JDBC escape functions: ACOS, ASIN, ATAN, COS, SIN, TAN, PI , DEGREES, RADIANS, EXP, LOG, LOG10, CEILING, FLOOR --- Key: DERBY-1549 URL: http://issues.apache.org/jira/browse/DERBY-1549 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.2.0.0 Reporter: Daniel John Debrunner Assigned To: Laura Stewart Attachments: derby1549_ref.diff, rrefjdbc88908.html Document in the reference manual in the section JDBC escape syntax for fn keyword -- 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-1603) ERROR 54038: Maximum depth of nested triggers was exceeded occurs when trigger fires after upating 10.1.2.5 jars to 10.1.3.1
Kathey Marsden wrote: Daniel John Debrunner wrote: Then I think this would lead to a simpler action statement of UPDATE TEST SET TIMESTAMP = CURRENT_TIMESTAMP WHERE TESTID = OLD.TESTID A statement trigger might be best in this case, would result in a single update statement rather than N. Hmmm Well, this (I think) is where we started and from what I understand from Yip is the case that is always supposed to give us the Maximum depth of nested triggers was exceeded error (DERBY-1652). If the trigger is defined this way, when the row is updated, it fires the update trigger which updates the row which fires the update trigger etc... I added the additional qualifier ( AND INFO != OLD.INFO to make it stop on the second fire. Is there a better way? OK, I see why the per-row was picked, but I think the better is the selective firing on the actual column being changed. Dan.
Re: [jira] Commented: (DERBY-1603) ERROR 54038: Maximum depth of nested triggers was exceeded occurs when trigger fires after upating 10.1.2.5 jars to 10.1.3.1
Another way is to specify which column in the trigger that will invoke the trigger action. i.e.:CREATE TRIGGER update_test AFTER UPDATE OF INFO ON test REFERENCING OLD AS old FOR EACH ROW MODE DB2SQL UPDATE test SET timestamp=current_timestamp WHERE testid=old.testid;On 8/7/06, Kathey Marsden [EMAIL PROTECTED] wrote:Daniel John Debrunner wrote:Then I think this would lead to a simpler action statement of UPDATE TEST SET TIMESTAMP = CURRENT_TIMESTAMP WHERE TESTID = OLD.TESTIDA statement trigger might be best in this case, would result in a singleupdate statement rather than N. HmmmWell, this (I think)is where we started and from what I understandfrom Yip isthe case that is always supposed to give us the Maximumdepth of nested triggers was exceeded error (DERBY-1652).If the trigger is defined this way, when the row is updated, it fires theupdate trigger which updates the row which fires the update triggeretc...I added the additional qualifier ( AND INFO != OLD.INFO to make it stop on the second fire. Is there a better way?Kathey
Regression Test Failure! - TinderBox_Derby 429352 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 429352/2006-08-07 16:22:25 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1687686 2 143.36% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-429352.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/429352.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/429352.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Commented: (DERBY-1637) OutBufferedStream.java fails on ibm131/jdk131 jvms.
[ http://issues.apache.org/jira/browse/DERBY-1637?page=comments#action_12426272 ] Sunitha Kambhampati commented on DERBY-1637: Thanks Tomohito for trying it out. If it looks ok, it would be great if you could commit this change. Thanks, Sunitha. 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: 1637_jcc2.4.zip, derby1637.draft.txt, javacore.20060804.101637.3308.txt, javacore.20060804.101643.3308.txt, outbuff_ibm131.jar, 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
[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: DERBY-1633_v1.html d1633_v1_reviewOnly.patch Attaching a detailed description of the issue that is causing this regression, and a description of what I believe to be the correct fix. I'm also attaching a first version of the patch that is for review only. The reason the patch is for review only is that it does not yet have new test cases for catching this regression in the future, and more importantly, because there are some changes in the patch about which I am not very clear. So I'm hoping someone out there who's familiar with predicate remapping can provide some input to help clarify some things for me. A description of what I don't yet understand is provided in section V of the document. I plan to continue looking at this issue to try to finalize my understanding of the changes, but in the meantime, other comments/reviews would be helpful. The description of the problem, the fix, and my continuing questions can be found in DERBY-1633_v1.html; the first patch (for review only) is d1633_v1_reviewOnly.patch. 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, d1633_v1_reviewOnly.patch, DERBY-1633_v1.html 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
Predicate / Column reference remapping, anyone? (w.r.t DERBY-1633)
I've spent a lot of time trying to understand the problem reported in DERBY-1633 and have just attached a description of the issue, along with a proposed fix, to that Jira entry. The fix isn't ready for commit, though, because it includes some changes for predicate remapping that I don't fully understand. The changes resolve the regression and pass all of my tests, but I haven't quite been able to nail down *why* these particular remapping changes are necessary. I'm still investigating this and hope to know more shortly, but in the meantime I thought I'd ask if anyone out there is familiar with predicate remapping and can perhaps help me see the justification for the changes I've made (that sounds weird, I know, but so it goes). My questions are described in section V of the DERBY-1633.html document attached to DERBY-1633. It is perhaps a long shot, but any feedback/comments could prove useful in resolving this blocker regression... Thanks, Army
Re: Code coverage results for trunk svn no 428586
Thanks, Ramandeep. Our code coverage seems to have improved modestly. For comparison, I'm attaching the results of your code-coverage run against 10.1.3. Regards, -Rick 10.2 run: Ramandeep Kaur wrote: Hi All, I ran code coverage for trunk - svn revision no 428586 with sun jdk131, sun jdk142, sun jdk15, and sun jdk16 on Windows 2000, and results are as following:- * OVERALL COVERAGE SUMMARY * Classes: 93% (1177/1260) Methods: 78% (16331/20921) Blocks: 75% (490643/658117) Lines: 75% (101611.2/136333) * OVERALL STATS SUMMARY * total packages: 79 total executable files: 1195 total classes: 1260 total methods: 20921 total executable lines: 136333 -- Ramandeep Kaur [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Ramandeep's code-coverage results for 10.1.3: I ran code coverage for 10.1.3 - svn revision no 417277 with sun jdk131, sun jdk142, sun jdk15 on Windows 2000, and results are as following:- *OVERALL COVERAGE SUMMARY* Classes: 92% (1071/1167) Methods: 74% (14839/20030) Blocks: 71% (445925/630514) Lines: 71% (92693.9/130494) *OVERALL STATS SUMMARY* total packages: 75 total executable files: 1118 total classes: 1167 total methods: 20030 total executable lines: 130494
Re: [jira] Commented: (DERBY-1603) ERROR 54038: Maximum depth of nested triggers was exceeded occurs when trigger fires after upating 10.1.2.5 jars to 10.1.3.1
Yip Ng wrote: Another way is to specify which column in the trigger that will invoke the trigger action. Thanks Yip and Dan.I will hold off on the release note until we have the fix and I understand the root cause and when the proper checking is/is not done. For example I'd like to understand if upgrade the only event that would cause Derby to start throwing the right error. Again I think this is an easy error for a user to make. I hope not too many have made it already. Kathey
Re: Code coverage results for trunk svn no 428586
Rick Hillegas wrote: Thanks, Ramandeep. Our code coverage seems to have improved modestly. For comparison, I'm attaching the results of your code-coverage run against 10.1.3. There is a history of code coverage here: http://wiki.apache.org/db-derby/CodeCoverage Dan.
Re: Code coverage results for trunk svn no 428586
On 8/7/06, Ramandeep Kaur [EMAIL PROTECTED] wrote: Hi All, I ran code coverage for trunk - svn revision no 428586 with sun jdk131, sun jdk142, sun jdk15, and sun jdk16 on Windows 2000, and results are as following:- These results now viewable at: http://people.apache.org/~fuzzylogic/codecoverage/428586/ One reason for the increase in coverage in these results is the inclusion of JDK 1.6. andrew
[jira] Commented: (DERBY-1554) IDENTITY_VAL_LOCAL() returned value is modified incorrectly by a multi-row INSERT statement.
[ http://issues.apache.org/jira/browse/DERBY-1554?page=comments#action_12426282 ] Rick Hillegas commented on DERBY-1554: -- Committed derby1554trunkdiff02.txt at subversion revision 429425. As Yip says, derbyall only shows the expected diffs in XATest and wisconsin. IDENTITY_VAL_LOCAL() returned value is modified incorrectly by a multi-row INSERT statement. Key: DERBY-1554 URL: http://issues.apache.org/jira/browse/DERBY-1554 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.0.0 Reporter: Daniel John Debrunner Assigned To: Yip Ng Fix For: 10.2.0.0 Attachments: DERBY-1554.diff, DERBY-1554.stat, derby1554trunkdiff01.txt, derby1554trunkdiff02.txt, derby1554trunkstat01.txt, derby1554trunkstat02.txt Changes made in DERBY-353 break the documented behaviour of IDENTITY_VAL_LOCAL(). Now the returned value is modified when a multi-row insert is performed. IDENTITY_VAL_LOCAL() should not be updated when this occurs. For this script the last value returned should be 2 (as in 10.1) but in 10.2 is 4 create table ta (a int, b int generated always as identity); insert into ta(a) values 100; values IDENTITY_VAL_LOCAL(); insert into ta(a) values 200; values IDENTITY_VAL_LOCAL(); insert into ta(a) values 300,400; values IDENTITY_VAL_LOCAL(); -- 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-1554) IDENTITY_VAL_LOCAL() returned value is modified incorrectly by a multi-row INSERT statement.
[ http://issues.apache.org/jira/browse/DERBY-1554?page=all ] Rick Hillegas updated DERBY-1554: - Derby Info: [Existing Application Impact, Regression] (was: [Existing Application Impact, Patch Available, Regression]) IDENTITY_VAL_LOCAL() returned value is modified incorrectly by a multi-row INSERT statement. Key: DERBY-1554 URL: http://issues.apache.org/jira/browse/DERBY-1554 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.0.0 Reporter: Daniel John Debrunner Assigned To: Yip Ng Fix For: 10.2.0.0 Attachments: DERBY-1554.diff, DERBY-1554.stat, derby1554trunkdiff01.txt, derby1554trunkdiff02.txt, derby1554trunkstat01.txt, derby1554trunkstat02.txt Changes made in DERBY-353 break the documented behaviour of IDENTITY_VAL_LOCAL(). Now the returned value is modified when a multi-row insert is performed. IDENTITY_VAL_LOCAL() should not be updated when this occurs. For this script the last value returned should be 2 (as in 10.1) but in 10.2 is 4 create table ta (a int, b int generated always as identity); insert into ta(a) values 100; values IDENTITY_VAL_LOCAL(); insert into ta(a) values 200; values IDENTITY_VAL_LOCAL(); insert into ta(a) values 300,400; values IDENTITY_VAL_LOCAL(); -- 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-1554) IDENTITY_VAL_LOCAL() returned value is modified incorrectly by a multi-row INSERT statement.
[ http://issues.apache.org/jira/browse/DERBY-1554?page=all ] Kathey Marsden updated DERBY-1554: -- Derby Info: [Regression] (was: [Existing Application Impact, Regression]) Now that this is fixed and we have returned to the previous behavior, there should no longer be Existing Application Impact, so unchecking that.. The Existing application checkbox should reflect the current state as it affects users. The idea is that users can generate a report of issues which have existing application impact and see what changes might affect their application. IDENTITY_VAL_LOCAL() returned value is modified incorrectly by a multi-row INSERT statement. Key: DERBY-1554 URL: http://issues.apache.org/jira/browse/DERBY-1554 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.0.0 Reporter: Daniel John Debrunner Assigned To: Yip Ng Fix For: 10.2.0.0 Attachments: DERBY-1554.diff, DERBY-1554.stat, derby1554trunkdiff01.txt, derby1554trunkdiff02.txt, derby1554trunkstat01.txt, derby1554trunkstat02.txt Changes made in DERBY-353 break the documented behaviour of IDENTITY_VAL_LOCAL(). Now the returned value is modified when a multi-row insert is performed. IDENTITY_VAL_LOCAL() should not be updated when this occurs. For this script the last value returned should be 2 (as in 10.1) but in 10.2 is 4 create table ta (a int, b int generated always as identity); insert into ta(a) values 100; values IDENTITY_VAL_LOCAL(); insert into ta(a) values 200; values IDENTITY_VAL_LOCAL(); insert into ta(a) values 300,400; values IDENTITY_VAL_LOCAL(); -- 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
[junit]- ability to check JDBC level replaces _app properties files
The JUnit setup now has methods that allow a test to check to see if the
vm supports levels of JDBC. The methods are in the class JDBC.
JDBC.vmSupportsJDBC2() // JDBC 2.0 or greater
JDBC.vmSupportsJDBC3() // JDBC 3.0 or greater
JDBC.vmSupportsJDBC4() // JDBC 4.0 or greater
JDBC.vmSupportsJSR169() // JSR 169
Junit tests can use these methods in their suites to control which tests
are run when it based upon a level of JDBC support, rather than using
the old harness method of _app.properties files and runjdk13=false etc.
Using these methods, instead of skipping in the the old harness, allows
the tests to be run correctly when run directly using JUnit test
runners, which of course is the eventual goal.
The additional benefit of the old harness mechanism is that the test can
be selective as to its setup, the UpdateXXXTest through the old harness
was not run on JSR169 altogether, using these methods all but one test
case are run on JSR169.
I believe the style for using these methods should be postive and not
negative, e.g. this test requires JDBC 3, not this test doesn't run
on JDBC 2 or JSR 169. It's always good to comment what feature of the
JDBC sub-set is required. Here's a couple of example uses:
(from UpdateXXXTest)
// requires java.math.BigDecimal
if (JDBC.vmSupportsJDBC2())
suite.addTest(new UpdateXXXTest(testUpdateBigDecimal));
(from ConcurrencyTest not yet committed)
// Requires holdability
if (JDBC.vmSupportsJDBC3() || JDBC.vmSupportsJSR169()) {
One issue around jdbc 4 Junit tests is that there is no reason to have
vmSupportsJDBC4 logic in the test, since the classes are compiled on
Java SE 6 they won't even load in older enviroments.
I will update the wiki with this info.
For several of the existing Junit tests they are disabled in foundation
and/or jdk13 with *no* comments as to why. It's always preferable to put
a comment syaing why it's excluded, and I think it's a valid reason for
a new test to say I haven't tested in foundation and/or jdk 13. This
then allows someone else, who cares about those environments, to try the
tests out. Without the comment one has to try and figure out if the test
won't be able to run in those environments due to some other requirement.
Dan.
[jira] Updated: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme
[ http://issues.apache.org/jira/browse/DERBY-528?page=all ] Francois Orsini updated DERBY-528: -- Attachment: 528_stat_v4.txt 528_diff_v4.txt Sunitha, many thanks for this excellent and thorough review. I've addressed all of the comments - I've run derbyall as well as derbynet/testSecMec.java and derbynet/dataSourcePermissions_net.java under different JVM's. Spurious diffs because of tabs/spaces etc Took care of them. Additional testing with securityMechanism=8 and BUILTIN When I had USRSSBPWD upgraded by default, it was exercised a lot more, throughout testSecMec.java and dataSourcePermissions_net.java I have added a new test as part of testSecMec.java - method is testUSRSSBPWD_with_BUILTIN() a) Actually, these are internal connection attributes, which are passed on the connection URL. There really are connection attributes except that they are not exposed - in a similar way as the DRDAID_ATTR attribute. Some attributes such as CRYPTO_EXTERNAL_KEY_VERIFY_FILE and referenced in DERBY-1151 are not. b) The 2 checks are necessary as support for USRSSBPWD SecMec only works if Derby's authentication scheme is BUILTIN or NONE. It has to be done this way as we cannot risk to go ahead and fail authenticating against the Derby engine later during parseSECCHK() - As the password substitute cannot be decrypted, I know for sure that I can regenerate it via the updated BUILTIN scheme which now gets support for it - And as far as the NONE authentication scheme, we do not care as we never check the password, so the password substitute will never get checked...This has to be checked/verified early enough and hence why it is being done during parseACCSEC(). c) Yes, dataSource_.getUser() can be different than dataSource_.propertyDefault_user if a non-null user is specified as part of the getConnection() in ClientDataSource or/and if some connectionAttributes are set via setConnectionAttributes() - also, datasource values can be updated when updateDataSourceValues() gets called in ClientDataSource.getConnection() - I did not want to update user_ as the processing of USRSSBPWD is pretty isolated - I think I could do it but I might want to treat it as a separate JIRA for the simple reason that even with other DRDA security mechanism such as EUSRIDPWD, we keep encrypting the original userName and not the one that gets passed via connection attributes...I think this needs to be addressed as a separate JIRA which I will enter to also fix the current behavior with some other SecMec...This of course, will *not* have any impact on the user authentication. Issues: 1) I had noted that one as well- I have fixed both EncryptionManager.java and AuthenticationServiceBase.java to use toHexByte() instead. 2) I removed it because it was duplicated and therefore set twice in the the updateDataSourceValues() method 3) Took care of them all 4) Took care of them all - going to enter a JIRA for the toHexByte, toHexString methods to be reconciled into one location when we have fully addressed the code sharing aspect of things. Ensured Javadoc was generated properly. Thanks. Am hoping Kathey can run testSecMec with JCC 2.6 and 2.8 and generate the 2 additional testSecMec.out master canon output files for DerbyNet... Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme - Key: DERBY-528 URL: http://issues.apache.org/jira/browse/DERBY-528 Project: Derby Issue Type: New Feature Components: Security Affects Versions: 10.1.1.0 Reporter: Francois Orsini Assigned To: Francois Orsini Fix For: 10.2.0.0 Attachments: 528_diff_v1.txt, 528_diff_v2.txt, 528_diff_v3.txt, 528_diff_v4.txt, 528_SecMec_Testing_Table.txt, 528_stat_v1.txt, 528_stat_v2.txt, 528_stat_v3.txt, 528_stat_v4.txt This JIRA will add support for (DRDA) Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme in the network client/server driver layers. Current Derby DRDA network client driver supports encrypted userid/password (EUSRIDPWD) via the use of DH key-agreement protocol - however current Open Group DRDA specifications imposes small prime and base generator values (256 bits) that prevents other JCE's to be used as java cryptography providers - typical minimum security requirements is usually of 1024 bits (512-bit absolute minimum) when using DH key-agreement protocol to generate a session key. Strong User ID and Password Substitute Authentication (USRSSBPWD) is part of DRDA specifications as another alternative to provide ciphered passwords across the wire. Support of USRSSBPWD authentication scheme will enable additional JCE's to be used when encrypted passwords are required across
[jira] Commented: (DERBY-1377) Update copyright headers to comply with new ASF policy
[ http://issues.apache.org/jira/browse/DERBY-1377?page=comments#action_12426294 ] Daniel John Debrunner commented on DERBY-1377: -- The question on legal-discuss http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200608.mbox/[EMAIL PROTECTED] and the answer http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200608.mbox/[EMAIL PROTECTED] indicates it's ok to remove the existing copyright statements in the derby source code that are like: Copyright [] The Apache Software Foundation or its licensors, as applicable. Update copyright headers to comply with new ASF policy -- Key: DERBY-1377 URL: http://issues.apache.org/jira/browse/DERBY-1377 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.0.0 Reporter: Jean T. Anderson Assigned To: David Van Couvering Fix For: 10.2.0.0 Attachments: DERBY-1377_NOTICE_diff.txt A new copyright header policy will take effect for distributions released starting on Sep 1, 2006. Committers will receive notification, but a heads up with details is in the legal-discuss thread starting with http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL PROTECTED] Date was 1-Aug-2006, is now 1-Sep-2006: http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200607.mbox/[EMAIL PROTECTED] -- 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-1130) Client should not allow databaseName to be set with setConnectionAttributes
[ http://issues.apache.org/jira/browse/DERBY-1130?page=all ]
Deepa Remesh updated DERBY-1130:
Attachment: d1130-client-v1.diff
d1130-client-v1.status
Attaching a patch 'd1130-client-v1.diff' which disallows databaseName attribute
to be set using setConnectionAttributes method in client data sources. Tests
added to jdbcapi/checkDataSource.java.
Ran derbynetclientmats using Sun jdk1.4.2 on Windows XP. No new failures.
Please take a look at this patch. If this is okay, I plan to upload another
patch to add a similar check for embedded data sources.
Client should not allow databaseName to be set with setConnectionAttributes
---
Key: DERBY-1130
URL: http://issues.apache.org/jira/browse/DERBY-1130
Project: Derby
Issue Type: Bug
Components: Network Client
Affects Versions: 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1,
10.1.2.2, 10.1.2.3, 10.2.0.0, 10.1.3.0, 10.1.2.4
Reporter: Kathey Marsden
Assigned To: Deepa Remesh
Attachments: d1130-client-v1.diff, d1130-client-v1.status,
derby-1130-v1.diff, derby-1130-v1.status
Per this thread, setConnectionAttributes should not set databaseName.
http://www.nabble.com/double-check-on-checkDataSource-t1187602.html#a3128621
Currently this is allowed for client but should be disabled. I think it is
OK to change because we have documented that client will be changed to match
embedded for implementation defined behaviour. Hopefully its use is rare as
most folks would use the standard setDatabaseName. Still there should be a
release not when the change is made and it would be better to change it
sooner than later:
Below is the repro.
Here is the output with Client
Djava DatabaseNameWithSetConnAttr
ds.setConnectionAttributes(databaseName=wombat;create=true)
ds.getDatabaseName() = null (should be null)
FAIL: Should not have been able to set databaseName with connection attributes
Also look for tests disabled with this bug number in the test
checkDataSource30.java
import java.sql.*;
import java.lang.reflect.Method;
public class DatabaseNameWithSetConnAttr{
public static void main(String[] args) {
try {
String attributes = databaseName=wombat;create=true;
org.apache.derby.jdbc.ClientDataSource ds = new
org.apache.derby.jdbc.ClientDataSource();
//org.apache.derby.jdbc.EmbeddedDataSource ds = new
//org.apache.derby.jdbc.EmbeddedDataSource();
System.out.println(ds.setConnectionAttributes( +
attributes + ));
ds.setConnectionAttributes(attributes);
System.out.println(ds.getDatabaseName() = +
ds.getDatabaseName()
+ (should be null) );
Connection conn = ds.getConnection();
} catch (SQLException e) {
String sqlState = e.getSQLState();
if (sqlState != null
sqlState.equals(XJ041))
{
System.out.println(PASS: An exception was
thrown trying to get a connetion from a datasource after setting databaseName
with setConnectionAttributes);
System.out.println(EXPECTED EXCEPTION: +
e.getSQLState()
+
- + e.getMessage());
return;
}
while (e != null)
{
System.out.println(FAIL - UNEXPECTED
EXCEPTION: + e.getSQLState());
e.printStackTrace();
e = e.getNextException();
}
return;
}
System.out.println(FAIL: Should not have been able to set
databaseName with connection attributes);
}
}
--
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-1130) Client should not allow databaseName to be set with setConnectionAttributes
[ http://issues.apache.org/jira/browse/DERBY-1130?page=all ]
Deepa Remesh updated DERBY-1130:
Fix Version/s: 10.2.0.0
Derby Info: [Patch Available]
Client should not allow databaseName to be set with setConnectionAttributes
---
Key: DERBY-1130
URL: http://issues.apache.org/jira/browse/DERBY-1130
Project: Derby
Issue Type: Bug
Components: Network Client
Affects Versions: 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1,
10.1.2.2, 10.1.2.3, 10.2.0.0, 10.1.3.0, 10.1.2.4
Reporter: Kathey Marsden
Assigned To: Deepa Remesh
Fix For: 10.2.0.0
Attachments: d1130-client-v1.diff, d1130-client-v1.status,
derby-1130-v1.diff, derby-1130-v1.status
Per this thread, setConnectionAttributes should not set databaseName.
http://www.nabble.com/double-check-on-checkDataSource-t1187602.html#a3128621
Currently this is allowed for client but should be disabled. I think it is
OK to change because we have documented that client will be changed to match
embedded for implementation defined behaviour. Hopefully its use is rare as
most folks would use the standard setDatabaseName. Still there should be a
release not when the change is made and it would be better to change it
sooner than later:
Below is the repro.
Here is the output with Client
Djava DatabaseNameWithSetConnAttr
ds.setConnectionAttributes(databaseName=wombat;create=true)
ds.getDatabaseName() = null (should be null)
FAIL: Should not have been able to set databaseName with connection attributes
Also look for tests disabled with this bug number in the test
checkDataSource30.java
import java.sql.*;
import java.lang.reflect.Method;
public class DatabaseNameWithSetConnAttr{
public static void main(String[] args) {
try {
String attributes = databaseName=wombat;create=true;
org.apache.derby.jdbc.ClientDataSource ds = new
org.apache.derby.jdbc.ClientDataSource();
//org.apache.derby.jdbc.EmbeddedDataSource ds = new
//org.apache.derby.jdbc.EmbeddedDataSource();
System.out.println(ds.setConnectionAttributes( +
attributes + ));
ds.setConnectionAttributes(attributes);
System.out.println(ds.getDatabaseName() = +
ds.getDatabaseName()
+ (should be null) );
Connection conn = ds.getConnection();
} catch (SQLException e) {
String sqlState = e.getSQLState();
if (sqlState != null
sqlState.equals(XJ041))
{
System.out.println(PASS: An exception was
thrown trying to get a connetion from a datasource after setting databaseName
with setConnectionAttributes);
System.out.println(EXPECTED EXCEPTION: +
e.getSQLState()
+
- + e.getMessage());
return;
}
while (e != null)
{
System.out.println(FAIL - UNEXPECTED
EXCEPTION: + e.getSQLState());
e.printStackTrace();
e = e.getNextException();
}
return;
}
System.out.println(FAIL: Should not have been able to set
databaseName with connection attributes);
}
}
--
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-1626) TransactionTable.sql fails
[ http://issues.apache.org/jira/browse/DERBY-1626?page=comments#action_12426319 ] Rajesh Kartha commented on DERBY-1626: -- I ran this test using Derby 10.2.0.5 alpha - (428936) jars on jdk15, ibm15 and jdk16 on Windows and Linux. No failures were seen while running in 'embedded' mode. With the 'DerbyNetClient' I do see some failures: For example with jdk15: *** Start: TransactionTable jdk1.5.0_02 DerbyNetClient 2006-08-07 12:43:51 *** 246 del ERROR 38000: The exception 'java.sql.SQLException: 'ALTER TABLE' is not allowed in the 'SYSCS_DIAG' schema.' was thrown while evaluating an expression. 247 del ERROR 42X62: 'ALTER TABLE' is not allowed in the 'SYSCS_DIAG' schema. 247a246 ERROR 38000: The exception 'java.sql.SQLException: 'ALTER TABLE' is not allowed in the 'SYSCS_DIAG' schema.' was thrown while evaluating an expression. SQLSTATE: 42X62: 'ALTER TABLE' is not allowed in the 'SYSCS_DIAG' schema. 249 del 0 rows inserted/updated/deleted 249a248 Statement executed. Test Failed. *** End: TransactionTable jdk1.5.0_02 DerbyNetClient 2006-08-07 12:44:24 *** At first glance it looks like a master update. Since this test is not run as a part of derbynetclientmats suite, the failure with client was not seen before I assume. Going forward, I think derbynetclientmats should incorporate this test as a part of DERBY-1040. TransactionTable.sql fails -- Key: DERBY-1626 URL: http://issues.apache.org/jira/browse/DERBY-1626 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 TransactionTable fails with the following diff: 226a227 NULL |SystemTransaction |IDLE|readonly|NULL Test Failed. *** End: TransactionTable jdk1.4.2_08 2006-08-01 12:47:35 *** -- 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-1646) Documentation to address Grant/Revoke Authorization for views/triggers/constraints/routines(DERBY-1330)
[ http://issues.apache.org/jira/browse/DERBY-1646?page=comments#action_12426331 ] Laura Stewart commented on DERBY-1646: -- Thank you for your comments. Before I start using connection access I want to make certain that we are not making this overly complex for Derby developers. In the security section of the Developers Guide (Security -Working with user authenticaionand Security -Users and authorization identifiers) the term user authentication is used pervasively and seems to coinside with the term you propose connection access. I don't really want to introduce a new term or change an existing term that is pervasive Or perhaps these sections are discussing something completely different? Documentation to address Grant/Revoke Authorization for views/triggers/constraints/routines(DERBY-1330) --- Key: DERBY-1646 URL: http://issues.apache.org/jira/browse/DERBY-1646 Project: Derby Issue Type: New Feature Components: Documentation Affects Versions: 10.2.0.0 Reporter: Mamta A. Satoor Assigned To: Laura Stewart Creating a separate jira entry for documentation of Grant/Revoke Authorization for views/triggers/constraints/routines(Engine changes are going as part of DERBY-1330). Will link this jira entry to DERBY-1330 -- 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-688: Some review comments and feedback
Hi Bryan,
Thanks so much for reviewing the changes and for verifying the patches. I
appreciate your time with this.
3) Who will run these tests, and when? If all the execution code is
optional, how do we ensure that it doesn't get broken?
I still have a couple of more patches to post to complete the XML work (phases
4, 5, ...). One of those patches (probably the final one) will enable the
xmlSuite to be run as part of derbyall. Due to the dependencies on Xalan and on
a JAXP implementation, the suite will not run against all JVMs: to start, I'll
just have it running against JVMs that have the required classes included in
them. This was originally going to be Sun and IBM 1.4, but as you discovered
this past weekend, the Xalan that's embedded with Sun jdk 1.4.2 is not a recent
enough version to pass. The tests cannot run against Sun 1.5 because the Xalan
classes have (I believe) been renamed in Sun jdk 1.5 and thus will not be
available to Derby (so far as I understand it, the user would have to download
an external version of Xalan, as with Sun jdk 1.4.2).
So at this point, I think the xmlSuite will only be run for IBM 1.4 and IBM 1.5,
since those jvms include Xalan 2.5 or greater and also include a JAXP parser.
So anyone running derbyall with either of those jvms would run the XML tests
automatically. That said, the nightly tests that are reported here:
http://people.apache.org/~fuzzylogic/derby_test_results/
show results against ibm1.4.2. So while XML failures will not show up in Ole's
report, we should at least be able to see them at the above-indicated URL.
4) Can you further explain the BY VALUE vs. BY REF behaviors? What do these
clauses mean, why is BY REF better, at what point would we want to
re-introduce BY VALUE, how does this manifest itself in the code?
The main way in which BY VALUE vs BY REF manifests itself in the code is when
dealing with variable bindings. SQL/XML[2006] defines a syntax by which a value
can be bound into a query expression. For example:
select
xmlserialize(
xmlquery('$ci/my/stuff' passing by ref xcol as ci empty on empty)
as clob)
from xt_1
In this query xcol is bound into the variable $ci and then the query is
executed. A key way in which BY REF and BY VALUE come into play, then, is when
comparison operations between more than one XML value are part of the query.
Take the following query:
select
xmlserialize(
xmlquery('$ci/[EMAIL PROTECTED] = $c2/[EMAIL PROTECTED]' passing by ref
xcol as ci, xcol as c2 empty on empty
)
as clob)
from xt_1
If ci and c2 are passed BY REF then the result of this query would be
true; if either was passed BY VALUE, the result would be false. This is
what I tried to capture in the comments in sqlgrammar.jj, where I have:
* [I]f the same XML value is passed BY REF into two different XML arguments
* for a single operator, then every node in the first XML argument must have an
* identical node in the second XML argument, and the ids for both nodes must be
* the same.
I admit that the comment there could use some more explanation--but hopefully I
can do that as a follow-up patch, instead of re-generate the patches from square
one...?
A while back I was prototyping some code to support XML binding and I found that
it was both easier and more efficient to support BY REF, so that's the
experience on which I've based the decision to use BY REF.
That said, though, it turns out that Xalan does not support variable binding (or
if it does, I haven't figured it out yet), so the difference between BY REF and
BY VALUE is just syntactic right now. I've chosen BY REF because that was
easiest for me to implement when I did the prototyping for variable binding, and
I think that's the way to go in future. If at any point someone wants to fry
the BY VALUE fish, then s/he should certainly feel free to do so :)
5) If/when you re-generate the patches, please use relative path names for
the files in the patches so that we don't get strings like
c:/private/derby_src/java in the file names.
Yes, will do. Sorry.
most of your examples and tests show the use of extremely tiny XML documents;
they can fit into literal strings and are at most a few hundred bytes long.
But in practice, XML documents are often ridiculous gigantic things which are
hundreds of thousands of bytes long, and people try not to manipulate them in
memory, but rather read them from files and write them to files, streaming
them through parsers and into in-memory DOM trees only as needed.
How does this work in Derby?
For 10.2 I am only working to add XML support to Derby in the SQL layer. I do
not plan to address XML-specific JDBC processing. I'm planning to include in
the documentation something to this effect:
begin doc
There is no JDBC-side support for the XML datatype in Derby. This means it is
not possible to bind directly into an XML value nor to retrieve an
[jira] Updated: (DERBY-402) INTERSECT/EXCEPT/UNION operators don't agree with documented behavior.
[ http://issues.apache.org/jira/browse/DERBY-402?page=all ] Rick Hillegas updated DERBY-402: Derby Info: (was: [Patch Available]) INTERSECT/EXCEPT/UNION operators don't agree with documented behavior. -- Key: DERBY-402 URL: http://issues.apache.org/jira/browse/DERBY-402 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.1.1.0, 10.0.2.2 Reporter: A B Fix For: 10.2.0.0 Attachments: derby-402_v02.diff, derby402Final.diff, rrefselectexpression.html, rrefsqlj1083019.html I noticed the following two differences between what the documentation (Reference Manual) says about UNION/INTERSECT/EXCEPT queries and what the actual Derby behavior is. I'm filing this issue as a single bug against Derby, but if it turns out later that this is really just a documentation issue, or that these are improvements instead of bugs, anyone should feel free to change the relevant fields in this issue... 1) -- p. 63 of the Reference Manual (PDF version): SelectExpression - Naming columns First paragraph in this section includes the following: When the SelectExpression appears in a UNION, INTERSECT, or EXCEPT operator, the names from the first SelectExpression are taken as the names for the columns in the result of the operation. But this doesn't appear to be true. Ex: ij select a from t1 union select b from t2; 1 // This 1 should be A, according to doc. --- 1 2 If this behavior is intentional, then an ORDER BY clause on a UNION/INTERSECT/EXCEPT result set can only reference the result columns by position (ex. would have to use order by 1 in the above query since order by a doesn't work (because the name of the result column isn't a)). Note that if both SelectExpressions have the same column name, then things work differently: ij select a from t1 union select b as a from t2; A // Now it's A instead of 1. --- 1 2 So what needs to be corrected here? The documentation or the code? 2) -- p. 133 of the Reference Manual: Dynamic Parameters - Where dynamic parameters are allowed Number 16 says a dynamic parameter is allowed to represent a column if it appears in a UNION, INTERSECT, or EXCEPT expression. But the two examples that it gives both fail: ij SELECT ? FROM t UNION SELECT 1 FROM t; ERROR 42X34: There is a ? parameter in the select list. This is not allowed. ij VALUES 1 UNION VALUES ?; ERROR 42X34: There is a ? parameter in the select list. This is not allowed. I also tried preparing these statements using JDBC, but they failed there with the same error.. -- 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
Beta Announcement and encouraging user testing
Dear Development Community, I find myself very concerned about the small amount of feedback we have gotten so far from the user community on 10.2. We have heard no feedback really positive or negative on the major new features, like grant/revoke, SUR, online-backup and JDBC 4.0. We've gotten a few bites for existing application testing for the RegressionSearchAndDestroy contest [1] and we have gotten a couple of regressions filed from users trying 10.2, but after a year of development I just don't have the feeling users are really out there pounding on it like they need to with such an incredibly concentrated beta period. How can we make a big splash with the Beta Announcement and follow-up to get users pounding on 10.2 to make sure this is a quality release? I am interested in ideas from the community. Kathey [1] http://wiki.apache.org/db-derby/RegressionSearchAndDestroy
[jira] Commented: (DERBY-1401) TestDataReader class in jdbcapi/Stream.java creates test data of which length is not equals to value passed as length of test data.
[
http://issues.apache.org/jira/browse/DERBY-1401?page=comments#action_12426348 ]
Manjula Kutty commented on DERBY-1401:
--
The patch for this issue had been comitted a while ago. Can we close it?
TestDataReader class in jdbcapi/Stream.java creates test data of which length
is not equals to value passed as length of test data.
---
Key: DERBY-1401
URL: http://issues.apache.org/jira/browse/DERBY-1401
Project: Derby
Issue Type: Bug
Components: Test
Reporter: Tomohito Nakayama
Assigned To: Tomohito Nakayama
Attachments: DERBY-1401.patch
In the work of DERBY-1301, I found this issue.
Seeing the code, next part in
org.apache.derbyTesting.functionTests.tests.jdbcapi.Stream.TestDataReader had
problem.
public int read( char[] cbuf,
int off,
int len ){
if(wroteLength = total)
return -1;
int i;
for(i = off ;
i off + len
wroteLength = total ;
i++, wroteLength ++){
cbuf[i] = (char) (wroteLength % 0x1L);
}
return i - off;
}
Problem exists in next part...
wroteLength = total
Because an evaluation of this expression is true when wroteLength equals
total,
test data is created beyond max length passed in total.
--
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_1320.txt Sorry for my mistake. Please find the new attached patch. I have included the bug number to the patch name. Please let me know if you have any problem while applying the patch 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_diff_1320.txt, svn_stat.txt, svn_stat_1320.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_1320.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_diff_1320.txt, svn_stat.txt, svn_stat_1320.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
Re: DERBY-688: ready for commit?
Otherwise, if any of my answers above would make you uncomfortable with committing the patches (or with approving their commit), please let me know and I will try to address your concerns. Hi Army, I am comfortable with your responses, and in my opinion the 5 patches are ready for commit. Is anybody else intending to review these patches over the next few days? If no other reviews are underway, I propose to commit these patches by Aug 10. A question: is it best that I should commit them as 5 separate commit operations? An alternative would be to apply all 5 patches to my sandbox, and then commit them with a single commit, which matches the way that I reviewed them, but does not match the way that they are attached to the JIRA issue. Is there any particular reason to favor one technique versus the other? thanks, bryan
[jira] Commented: (DERBY-1646) Documentation to address Grant/Revoke Authorization for views/triggers/constraints/routines(DERBY-1330)
[ http://issues.apache.org/jira/browse/DERBY-1646?page=comments#action_12426357 ] Laura Stewart commented on DERBY-1646: -- I reread the sections on user authorization and user authentication... and I now see that I was confused. I will add the term connection access and clarify the topics so that others don't get confused as well :-) Documentation to address Grant/Revoke Authorization for views/triggers/constraints/routines(DERBY-1330) --- Key: DERBY-1646 URL: http://issues.apache.org/jira/browse/DERBY-1646 Project: Derby Issue Type: New Feature Components: Documentation Affects Versions: 10.2.0.0 Reporter: Mamta A. Satoor Assigned To: Laura Stewart Creating a separate jira entry for documentation of Grant/Revoke Authorization for views/triggers/constraints/routines(Engine changes are going as part of DERBY-1330). Will link this jira entry to DERBY-1330 -- 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-688: ready for commit?
Bryan Pendleton wrote: Otherwise, if any of my answers above would make you uncomfortable with committing the patches (or with approving their commit), please let me know and I will try to address your concerns. Hi Army, I am comfortable with your responses, and in my opinion the 5 patches are ready for commit. Is anybody else intending to review these patches over the next few days? If no other reviews are underway, I propose to commit these patches by Aug 10. A question: is it best that I should commit them as 5 separate commit operations? An alternative would be to apply all 5 patches to my sandbox, and then commit them with a single commit, which matches the way that I reviewed them, but does not match the way that they are attached to the JIRA issue. Is there any particular reason to favor one technique versus the other? I'd vote for separate patches it makes it easier to identify as a cause of a regression after the fact. http://wiki.apache.org/db-derby/IncrementalDevelopment Dan.
Regression Test Failure! - TinderBox_Derby 429468 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 429468/2006-08-07 22:43:07 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1687686 2 147.55% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-429468.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/429468.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/429468.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Updated: (DERBY-646) In-memory backend storage support
[ http://issues.apache.org/jira/browse/DERBY-646?page=all ] David Van Couvering updated DERBY-646: -- Derby Info: [Patch Available, Release Note Needed] In-memory backend storage support - Key: DERBY-646 URL: http://issues.apache.org/jira/browse/DERBY-646 Project: Derby Issue Type: New Feature Components: Store Environment: All Reporter: Stephen Fitch Assigned To: Stephen Fitch Attachments: svn.diff To allow creation and modification of databases in-memory without requiring disk access or space to store the database. -- 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-646) In-memory backend storage support
[ http://issues.apache.org/jira/browse/DERBY-646?page=comments#action_12426368 ] David Van Couvering commented on DERBY-646: --- Are separate tests needed for this feature. Isn't this a configuration option, e.g. couldn't we run the storemats suite with the system configured to use this store module? In-memory backend storage support - Key: DERBY-646 URL: http://issues.apache.org/jira/browse/DERBY-646 Project: Derby Issue Type: New Feature Components: Store Environment: All Reporter: Stephen Fitch Assigned To: Stephen Fitch Attachments: svn.diff To allow creation and modification of databases in-memory without requiring disk access or space to store the database. -- 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-646) In-memory backend storage support
[ http://issues.apache.org/jira/browse/DERBY-646?page=comments#action_12426372 ] Daniel John Debrunner commented on DERBY-646: - Probably no new tests are required but some changes to ensure the feature is tested, such as the ability to run tests with this configuration and suites that use the configuration. As in my earlier comments, I don't think this patch is ready to be committed, my concern is the new classes added to the publi api, with no coments or documentation as to what they are for. Why would a release not be needed? In-memory backend storage support - Key: DERBY-646 URL: http://issues.apache.org/jira/browse/DERBY-646 Project: Derby Issue Type: New Feature Components: Store Environment: All Reporter: Stephen Fitch Assigned To: Stephen Fitch Attachments: svn.diff To allow creation and modification of databases in-memory without requiring disk access or space to store the database. -- 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
Relicensing project
Hi, all. I've uploaded the scripts to http://wiki.apache.org/db-derby/FixingLicenseHeader. This means you, yes you, can help with the relicensing project. Take a look at the Wiki page, all you need to know should be there. It's *possible* that we don't have to get all this done in time for 10.2. But at this point I'm not counting on it, and am assuming we should get this done in time for the 10.2 branch that is scheduled to happen at the end of this week. So, while you're waiting for derbyall to finish, pick a directory, sign up for it, run the scripts, review it, build it, and either submit the patch to the JIRA (http://issues.apache.org/jira/browse/DERBY-1377) if you're a contributor, or commit it if you're a committer. I will thank you, Rick will thank you, the Apache legal team will thank you, and hey, that's gotta be worth something. I'd offer chocolate to the person with the most directories checked in, but I don't want to compete with the Regression Challenge... David
Re: Relicensing project
David Van Couvering wrote: Hi, all. I've uploaded the scripts to http://wiki.apache.org/db-derby/FixingLicenseHeader. This means you, yes you, can help with the relicensing project. Just to be pedantic, we are not relicensing Derby. Dan.
Re: [jira] Commented: (DERBY-646) In-memory backend storage support
I see your point about new classes added to the public API needing javadoc, that seems reasonable. By release, do you mean a Derby release or an ICLA? Assuming the latter, I thought the ICLA issue had been cleared up. The ICLA has been on file for some time, search for Stephen Fitch in http://people.apache.org/~jim/committers.html. David Daniel John Debrunner (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-646?page=comments#action_12426372 ] Daniel John Debrunner commented on DERBY-646: - Probably no new tests are required but some changes to ensure the feature is tested, such as the ability to run tests with this configuration and suites that use the configuration. As in my earlier comments, I don't think this patch is ready to be committed, my concern is the new classes added to the publi api, with no coments or documentation as to what they are for. Why would a release not be needed? In-memory backend storage support - Key: DERBY-646 URL: http://issues.apache.org/jira/browse/DERBY-646 Project: Derby Issue Type: New Feature Components: Store Environment: All Reporter: Stephen Fitch Assigned To: Stephen Fitch Attachments: svn.diff To allow creation and modification of databases in-memory without requiring disk access or space to store the database.
Re: [jira] Commented: (DERBY-646) In-memory backend storage support
David Van Couvering wrote: I see your point about new classes added to the public API needing javadoc, that seems reasonable. By release, do you mean a Derby release. I missed an 'e'. You checked the 'Release Note Needed' flag, why would a release note be needed? Dan.
Re: [jira] Commented: (DERBY-646) In-memory backend storage support
I guess it's not a regression or bug, so not a release note, but I didn't know how else to indicate that documentation was needed, given that it's a new feature... David Daniel John Debrunner wrote: David Van Couvering wrote: I see your point about new classes added to the public API needing javadoc, that seems reasonable. By release, do you mean a Derby release. I missed an 'e'. You checked the 'Release Note Needed' flag, why would a release note be needed? Dan.
Re: [jira] Commented: (DERBY-646) In-memory backend storage support
David Van Couvering wrote: I guess it's not a regression or bug, so not a release note, but I didn't know how else to indicate that documentation was needed, given that it's a new feature... A new Jira entry indicating documentation is needed. :-) Dan.
Regression Test Failure! - TinderBox_Derby 429515 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 429515/2006-08-08 01:52:58 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1687686 2 147.62% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-429515.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/429515.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/429515.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Commented: (DERBY-1565) Adjust documentation to comply with latest Apache copyright/license requirements
[ http://issues.apache.org/jira/browse/DERBY-1565?page=comments#action_12426396 ] Andrew McIntyre commented on DERBY-1565: Committed revision 429543, which updates the headers in the source files. The work to insert the header into the comments of the built documentation is pending. Adjust documentation to comply with latest Apache copyright/license requirements Key: DERBY-1565 URL: http://issues.apache.org/jira/browse/DERBY-1565 Project: Derby Issue Type: Sub-task Components: Documentation Affects Versions: 10.2.0.0 Reporter: David Van Couvering Assigned To: Andrew McIntyre Fix For: 10.2.0.0 Part of converting over to the new requirements is to fix the documentation. I am making this a separate subtask as I think this could better be handled by someone more conversant with DITA and the docs build process. -- 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_12426397 ]
Craig Russell commented on DERBY-1516:
--
I have run derby-all with these changes, and no errors were reported.
Any other comments before I check this in?
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,
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] Resolved: (DERBY-1614) Test harness overrides heap size settings when starting Network Server
[ http://issues.apache.org/jira/browse/DERBY-1614?page=all ] Andrew McIntyre resolved DERBY-1614. Resolution: Fixed Derby Info: (was: [Patch Available]) Committed to trunk with revision 429550. 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, DERBY-1614_v2.diff, DERBY-1614_v3.diff Test specific heap size settings can be passed to the test harness using the jvmflags system property, for example in a testname_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] Resolved: (DERBY-1431) Typo in link to Simple Example from frameworks/readme.html
[ http://issues.apache.org/jira/browse/DERBY-1431?page=all ] Andrew McIntyre resolved DERBY-1431. Fix Version/s: 10.2.0.0 Resolution: Fixed Derby Info: (was: [Patch Available]) Committed -alt2 patch to trunk with revision 429551. Typo in link to Simple Example from frameworks/readme.html -- Key: DERBY-1431 URL: http://issues.apache.org/jira/browse/DERBY-1431 Project: Derby Issue Type: Bug Components: Demos/Scripts, Documentation Affects Versions: 10.1.2.1, 10.1.3.1, 10.2.0.0 Reporter: Bryan Pendleton Assigned To: Andrew McIntyre Priority: Trivial Fix For: 10.2.0.0 Attachments: derby-1431-alt.diff, derby-1431-alt2.diff, docPatch.diff There is a small typo in frameworks/readme.html. The link see the simple example links to ../demo/programs/simple/example.html but it should link to ../demo/simple/example.html because there is no programs folder in the demo subtree. I'm attaching a patch for review. -- 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-1320) Test lang/procedure.java fails with ibm1.5 jvm
[ http://issues.apache.org/jira/browse/DERBY-1320?page=all ] Andrew McIntyre resolved DERBY-1320. Resolution: Fixed Derby Info: (was: [Patch Available]) Checked in patch svn_diff_1320.txt with revision 429561. 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_diff_1320.txt, svn_stat.txt, svn_stat_1320.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
sysinfo in derbyclient.jar? (was Re: (DERBY-1470) )
The issue below brings up an interesting question. The attached diff for this issue adds derby.jar to the classpath so that the user can run sysinfo and verify that their classpath is correct. However, a minimally configured client would only have derbyclient.jar, and I think we should be promoting this, even with the simple example html. So, perhaps a better solution would be to put sysinfo into the client jar, as we've done with derbynet.jar, so that one can get sysinfo out of any of the derby jars. Now that client is being built with classlister, it's a one-line change to tools/jar/dnc.properties. Doing so adds 11k to derbyclient.jar, making it 371 k vs. 360k when built insane. Opinions, anyone? andrew On 8/7/06, Ramandeep Kaur (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-1470?page=all ] Ramandeep Kaur updated DERBY-1470: -- Attachment: DERBY-1470.diff Submitting diffs. Please review it. Correct instructions in demo html file demo\simple\example.html --- Key: DERBY-1470 In file demo\simple\example.html, under section Next run the SimpleApp demo in Derby client mode:, step 5 java org.apache.derby.tools.sysinfo -cp client SimpleApp.class gives the following error: Exception in thread main java.lang.NoClassDefFoundError: org/apache/derby/tools/sysinfo Actually,
[jira] Updated: (DERBY-1470) Correct instructions in demo html file demo\simple\example.html
[ http://issues.apache.org/jira/browse/DERBY-1470?page=all ]
Andrew McIntyre updated DERBY-1470:
---
Attachment: derby-1470-alt.diff
Attaching alternate patch for this issue, which adds sysinfo to
derbyclient.jar, so that sysinfo can be obtained from a classpath that contains
only the client jar.
Correct instructions in demo html file demo\simple\example.html
---
Key: DERBY-1470
URL: http://issues.apache.org/jira/browse/DERBY-1470
Project: Derby
Issue Type: Bug
Components: Demos/Scripts
Affects Versions: 10.2.0.0, 10.1.3.1
Environment: Any platform on which we support derby
Reporter: Ramandeep Kaur
Assigned To: Ramandeep Kaur
Priority: Minor
Fix For: 10.2.0.0
Attachments: derby-1470-alt.diff, DERBY-1470.diff
In file demo\simple\example.html, under section Next run the SimpleApp demo
in Derby client mode:, step 5
java org.apache.derby.tools.sysinfo -cp client SimpleApp.class gives the
following error:
Exception in thread main java.lang.NoClassDefFoundError:
org/apache/derby/tools/sysinfo
The above error is given because step 4 instructs to set path as following:
export CLASSPATH=.:${DERBY_INSTALL}/lib/derbyclient.jar
Now as neither derby.jar or derbytool.jar is been added to the above
classpath, sysinfo file not found.
Step 4 should instruct to set up path as following:
export
CLASSPATH=.:${DERBY_INSTALL}/lib/derbyclient.jar:${DERBY_INSTALL}/lib/derby.jar
--
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-1470) Correct instructions in demo html file demo\simple\example.html
[ http://issues.apache.org/jira/browse/DERBY-1470?page=all ]
Andrew McIntyre updated DERBY-1470:
---
Derby Info: [Patch Available]
Correct instructions in demo html file demo\simple\example.html
---
Key: DERBY-1470
URL: http://issues.apache.org/jira/browse/DERBY-1470
Project: Derby
Issue Type: Bug
Components: Demos/Scripts
Affects Versions: 10.2.0.0, 10.1.3.1
Environment: Any platform on which we support derby
Reporter: Ramandeep Kaur
Assigned To: Ramandeep Kaur
Priority: Minor
Fix For: 10.2.0.0
Attachments: derby-1470-alt.diff, DERBY-1470.diff
In file demo\simple\example.html, under section Next run the SimpleApp demo
in Derby client mode:, step 5
java org.apache.derby.tools.sysinfo -cp client SimpleApp.class gives the
following error:
Exception in thread main java.lang.NoClassDefFoundError:
org/apache/derby/tools/sysinfo
The above error is given because step 4 instructs to set path as following:
export CLASSPATH=.:${DERBY_INSTALL}/lib/derbyclient.jar
Now as neither derby.jar or derbytool.jar is been added to the above
classpath, sysinfo file not found.
Step 4 should instruct to set up path as following:
export
CLASSPATH=.:${DERBY_INSTALL}/lib/derbyclient.jar:${DERBY_INSTALL}/lib/derby.jar
--
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-1470) Correct instructions in demo html file demo\simple\example.html
[
http://issues.apache.org/jira/browse/DERBY-1470?page=comments#action_12426436 ]
Daniel John Debrunner commented on DERBY-1470:
--
I would say step 4) above is wrong, the up front introduction examples should
not be giving the impression that derby.jar is required on the client side.
The alternative would be to have derbytools.jar, which is logical to have on
the client.
Adding sysinfo to the client jar seems to make sense as well.
Correct instructions in demo html file demo\simple\example.html
---
Key: DERBY-1470
URL: http://issues.apache.org/jira/browse/DERBY-1470
Project: Derby
Issue Type: Bug
Components: Demos/Scripts
Affects Versions: 10.2.0.0, 10.1.3.1
Environment: Any platform on which we support derby
Reporter: Ramandeep Kaur
Assigned To: Ramandeep Kaur
Priority: Minor
Fix For: 10.2.0.0
Attachments: derby-1470-alt.diff, DERBY-1470.diff
In file demo\simple\example.html, under section Next run the SimpleApp demo
in Derby client mode:, step 5
java org.apache.derby.tools.sysinfo -cp client SimpleApp.class gives the
following error:
Exception in thread main java.lang.NoClassDefFoundError:
org/apache/derby/tools/sysinfo
The above error is given because step 4 instructs to set path as following:
export CLASSPATH=.:${DERBY_INSTALL}/lib/derbyclient.jar
Now as neither derby.jar or derbytool.jar is been added to the above
classpath, sysinfo file not found.
Step 4 should instruct to set up path as following:
export
CLASSPATH=.:${DERBY_INSTALL}/lib/derbyclient.jar:${DERBY_INSTALL}/lib/derby.jar
--
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-1597) Scripts in frameworks direcotry needs to be revisted to set up CLASSPATH properly
[
http://issues.apache.org/jira/browse/DERBY-1597?page=comments#action_12426438 ]
Andrew McIntyre commented on DERBY-1597:
The attached patch is ok, but I think that we should put $CLASSPATH first in
the list of arguments to -cp, in case the user wants to override the Derby jars
in their installation with another set that they have put into their classpath.
Comments?
Scripts in frameworks direcotry needs to be revisted to set up CLASSPATH
properly
-
Key: DERBY-1597
URL: http://issues.apache.org/jira/browse/DERBY-1597
Project: Derby
Issue Type: Bug
Components: Demos/Scripts
Affects Versions: 10.2.0.0
Reporter: Ramandeep Kaur
Assigned To: Andrew McIntyre
Attachments: DERBY-1597.diff
Need to revisit scripts in directory frameworks/embedded/bin and
frameworks/NetworkServer/bin for setting up CLASSPATH properly. The current
problem is as following:
If user already has a CLASSPATH set on their system, the CLASSPATH is not set
again within the script. Therefore, there are no derby classes in the
CLASSPATH which results in java command failing as it can not find the derby
class it is calling. Basically, to make the scripts work, user has to either
issue command set CLASSPATH= or have derby jar files be appended to their
system CLASSPATH before running any frameworks batch script.
In ksh scripts, there is same problem except that the user has to issue
command export CLASSPATH= or have derby jar files be appended to their
system CLASSPATH only once as whatever CLASSPATH is set up by scripts is not
visible once the script is done.
So I am proposing the following solution so that frameworks scripts work
properly without interfering with system classpath or without any setup from
user.
In batch scripts:-
--
1. Before line call
%DERBY_INSTALL%/frameworks/embedded/bin/setEmbeddedCP.bat, save the
current classpath as follows:
set SAVED_CLASSPATH=%CLASSPATH%
2. Replace the following lines:
@if !%CLASSPATH%==! call
%DERBY_INSTALL%/frameworks/embedded/bin/setEmbeddedCP.bat
@if %CLASSPATH% == call
%DERBY_INSTALL%/frameworks/embedded/bin/setEmbeddedCP.bat
with
call %DERBY_INSTALL%/frameworks/embedded/bin/setEmbeddedCP.bat
Note: I have given the above as example only. The name of script that is
getting called may be different.
3. At the end of script, reset the CLASSPATH to system CLASSPATH as follows:
set CLASSPATH=%SAVED_CLASSPATH%
In korn scripts:-
--
In ksh script, even though system classpath is only modified within the
script and is not effective once script exits, to be consistent with batch
scripts, do the following:
1. Before line . $DERBY_HOME/frameworks/embedded/bin/setEmbeddedCP.ksh
save the current classpath as follows:
export SAVED_CLASSPATH=$CLASSPATH
2. Replace the following lines:
[ -z $CLASSPATH ] {
. $DERBY_HOME/frameworks/embedded/bin/setEmbeddedCP.ksh
}
with
. $DERBY_HOME/frameworks/embedded/bin/setEmbeddedCP.ksh
Note: I have given the above as example only. The name of script that is
getting called may be different.
3. At the end of script, reset the CLASSPATH to system CLASSPATH as follows:
export CLASSPATH=$SAVED_CLASSPATH
--
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-1470) Correct instructions in demo html file demo\simple\example.html
[ http://issues.apache.org/jira/browse/DERBY-1470?page=all ]
Andrew McIntyre updated DERBY-1470:
---
Attachment: derby-1470-alt2.diff
Attaching a second version of the alternate solution for this issue, this
version also unseals the newly added impl/tools/sysinfo package in
derbyclient.jar.
Correct instructions in demo html file demo\simple\example.html
---
Key: DERBY-1470
URL: http://issues.apache.org/jira/browse/DERBY-1470
Project: Derby
Issue Type: Bug
Components: Demos/Scripts
Affects Versions: 10.2.0.0, 10.1.3.1
Environment: Any platform on which we support derby
Reporter: Ramandeep Kaur
Assigned To: Ramandeep Kaur
Priority: Minor
Fix For: 10.2.0.0
Attachments: derby-1470-alt.diff, derby-1470-alt2.diff,
DERBY-1470.diff
In file demo\simple\example.html, under section Next run the SimpleApp demo
in Derby client mode:, step 5
java org.apache.derby.tools.sysinfo -cp client SimpleApp.class gives the
following error:
Exception in thread main java.lang.NoClassDefFoundError:
org/apache/derby/tools/sysinfo
The above error is given because step 4 instructs to set path as following:
export CLASSPATH=.:${DERBY_INSTALL}/lib/derbyclient.jar
Now as neither derby.jar or derbytool.jar is been added to the above
classpath, sysinfo file not found.
Step 4 should instruct to set up path as following:
export
CLASSPATH=.:${DERBY_INSTALL}/lib/derbyclient.jar:${DERBY_INSTALL}/lib/derby.jar
--
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
