Re: [jira] Commented: (DERBY-577) Test harness should not change the user.dir property , it is meant for infomative purpose only.
Hi, I don't think this is needed in 10.1, but Suresh logged this, Suresh, what say you? Myrna On 5/10/06, Andrew McIntyre (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-577?page=comments#action_12378843 ]Andrew McIntyre commented on DERBY-577:---Committed to trunk with revision 405670. Do you need this in 10.1? Testharness should not change the user.dir property , it is meant for infomative purpose only. Key: DERBY-577URL: http://issues.apache.org/jira/browse/DERBY-577Project: Derby Type: Improvement Components: Test Versions: 10.2.0.0 Reporter: Suresh Thalamati Assignee: Myrna van Lunteren Priority: MinorAttachments: DERBY-577_102_20060509.diff, DERBY-577_102_20060509.stat Iftheuser.dir property is changed ,you wilfind IO calls are working on different directory than what is returnedby File.getAbsolutePath() if the file handle is created with a relative pathbecause of JVM issue: 4117557 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4117557 I thinkitisnot goodidea for test harness to changethe user.dir property.It makes hard to debug tests ,because filesare not createdatdiferent location thanwhat is returned by getAbsolutePath().Atleast, I hadfun time figuring out this :-) user.diris beingchanged at the following code segment : org.apache.derbyTesting.functionTests.harness. RunTest.javatestJvmProps.addElement(user.dir=+userDirName);--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-577) Test harness should not change the user.dir property , it is meant for infomative purpose only.
[ http://issues.apache.org/jira/browse/DERBY-577?page=comments#action_12378843 ] Andrew McIntyre commented on DERBY-577: --- Committed to trunk with revision 405670. Do you need this in 10.1? Test harness should not change the user.dir property , it is meant for infomative purpose only. Key: DERBY-577 URL: http://issues.apache.org/jira/browse/DERBY-577 Project: Derby Type: Improvement Components: Test Versions: 10.2.0.0 Reporter: Suresh Thalamati Assignee: Myrna van Lunteren Priority: Minor Attachments: DERBY-577_102_20060509.diff, DERBY-577_102_20060509.stat If the user.dir property is changed , you wil find IO calls are working on different directory than what is returned by File.getAbsolutePath() if the file handle is created with a relative path because of JVM issue: 4117557 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4117557 I think it is not good idea for test harness to change the user.dir property.It makes hard to debug tests , because files are not created at diferent location than what is returned by getAbsolutePath().Atleast, I had fun time figuring out this :-) user.dir is being changed at the following code segment : org.apache.derbyTesting.functionTests.harness. RunTest.java testJvmProps.addElement(user.dir=+userDirName); -- 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-1251) cancelRowUpdates() affects rows updated with updateRow() in scrollable updatable resultsets
[
http://issues.apache.org/jira/browse/DERBY-1251?page=comments#action_12378856 ]
Andreas Korneliussen commented on DERBY-1251:
-
- //After a delete, the ResultSet will be positioned right before
- //the next row.
- rowData = null;
- currentRow = null;
+ //For forward only resultsets, after a delete,
+ // the ResultSet will be positioned right before the next row.
+ if (getType() == TYPE_FORWARD_ONLY) {
+ currentRow.setRowArray(null);
+ } else {
+ movePosition(RELATIVE, 0, relative);
+ }
According to JDBC 3.0 specification section 14.2.4.2 Deleting a Row, after a
deleteRow has been called, the cursor will be positioned before the next valid
row. Is there a reason to make this comment specific to forward only result
sets?
This is a good point. For FORWARD_ONLY resultsets, this means that the cursor
is not on a row (i.e all getXXX(..) methods throws exception), and when calling
next the cursor will be positioned on the next row.
For SCROLL INSENSITIVE cursors, I am a bit unsure if the current row (which has
been deleted) is valid or not. If it is valid, it is correct to be on the
current row, since it is before the next valid row. If it is considered as
invalid the cursor should be position somewhere inbetween the current row and
the next row (i.e not on a row).
Then the behavior would be that: calling next() will give the next row, calling
previous will give the previous row, and calling relative(0) will give the
current invalid (deleted) row in scroll insensitive resultsets.
However I choose to not deal with this in this patch. The call to
movePosition(RELATIVE..) should not be part of the patch, it could be added in
another patch, i.e if we choose to consider the current row as a valid row
after it has been deleted.
cancelRowUpdates() affects rows updated with updateRow() in scrollable
updatable resultsets
---
Key: DERBY-1251
URL: http://issues.apache.org/jira/browse/DERBY-1251
Project: Derby
Type: Bug
Components: JDBC, Network Client
Versions: 10.2.0.0
Reporter: Andreas Korneliussen
Assignee: Andreas Korneliussen
Priority: Minor
Attachments: DERBY-1251.diff, DERBY-1251.stat, DERBY-1251v2.diff,
DERBY-1251v2.stat, derbyall_report.txt, derbyall_report.txt
If an application does the following:
rs.updateInt(1, newValueCol1);
rs.updateRow();
rs.updateInt(2, newValueCol2);
rs.cancelRowUpdates();
Then, when calling rs.getInt(1), it will return the old value. Instead it
should return the new value.
Workaround: after calling rs.updateRow(), the application could call
rs.relative(0).
This problem does not affect forward only resultsets, since after an
updateRow() they get positoned before the next row, leaving it impossible to
do anything with the current row.
--
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-1251) cancelRowUpdates() affects rows updated with updateRow() in scrollable updatable resultsets
[ http://issues.apache.org/jira/browse/DERBY-1251?page=all ] Andreas Korneliussen updated DERBY-1251: Attachment: DERBY-1251v3.diff Attached is a patch (DERBY-1251v3.diff) which addresses the review comments. The changes in deleteRow() behavior has been removed. cancelRowUpdates() affects rows updated with updateRow() in scrollable updatable resultsets --- Key: DERBY-1251 URL: http://issues.apache.org/jira/browse/DERBY-1251 Project: Derby Type: Bug Components: JDBC, Network Client Versions: 10.2.0.0 Reporter: Andreas Korneliussen Assignee: Andreas Korneliussen Priority: Minor Attachments: DERBY-1251.diff, DERBY-1251.stat, DERBY-1251v2.diff, DERBY-1251v2.stat, DERBY-1251v3.diff, derbyall_report.txt, derbyall_report.txt If an application does the following: rs.updateInt(1, newValueCol1); rs.updateRow(); rs.updateInt(2, newValueCol2); rs.cancelRowUpdates(); Then, when calling rs.getInt(1), it will return the old value. Instead it should return the new value. Workaround: after calling rs.updateRow(), the application could call rs.relative(0). This problem does not affect forward only resultsets, since after an updateRow() they get positoned before the next row, leaving it impossible to do anything with the current row. -- 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
Developer access to Jira
I would like to be granted developer access to Jira. It seems I need this to be able to close a bug I reported. Thanks, Vemund
Regression Test Failure! - Derby 405484 - Sun DBTG
[Auto-generated mail] *Derby* 405484/2006-05-09 19:46:06 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 130674544 0 101.56% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJDK16Jvm1.6/Limited/testSummary-405484.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJDK16Jvm1.6/405484.html *Jvm: 1.5* 6659653 1 105.16% CYGWIN_NT-5.1_i686-unknown 3659656 1 112.96% CYGWIN_NT-5.2_i686-unknown 5659654 1 144.21% Linux-2.6.14-1.1644_FC4_i686-i686 2659657 1 102.90% Linux-2.6.9-34.ELsmp_x86_64-x86_64 2659657 1 109.64% SunOS-5.10_i86pc-i386 2659657 1 134.05% SunOS-5.10_sun4u-sparc 3659656 1 107.46% SunOS-5.11_i86pc-i386 2659657 1 109.84% SunOS-5.9_sun4u-sparc Details in http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-405484.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/Derby/405484.html *Jvm: 1.4* 6653647 3 101.66% CYGWIN_NT-5.1_i686-unknown 3653650 3 115.40% Linux-2.6.14-1.1644_FC4_i686-i686 2653651 3 103.46% Linux-2.6.9-34.ELsmp_x86_64-x86_64 3653650 3 111.74% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-405484.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJvm1.4/405484.html Changes in http://www.multinet.no/~solberg/public/Apache/Derby/UpdateInfo/405484.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Closed: (DERBY-1288) Bring Derby into JDBC compliance by supporting executeQuery() on escaped procedure invocations
[ http://issues.apache.org/jira/browse/DERBY-1288?page=all ]
Knut Anders Hatlen closed DERBY-1288:
-
Fix Version: (was: 10.2.0.0)
Resolution: Duplicate
Duplicate of DERBY-501.
Bring Derby into JDBC compliance by supporting executeQuery() on escaped
procedure invocations
--
Key: DERBY-1288
URL: http://issues.apache.org/jira/browse/DERBY-1288
Project: Derby
Type: Improvement
Components: JDBC
Versions: 10.2.0.0
Reporter: Rick Hillegas
Assignee: Knut Anders Hatlen
The following statement raises an error in Derby:
statement.executeQuery( {call foo()} );
although this statement works:
statement.executeUpdate( {call foo()} );
According to section 6.4 of the latest draft of the JDBC4 Compliance chapter,
both statements are supposed to work in order to claim Java EE JDBC
Compliance.
We need to bring Derby into compliance by supporting executeQuery() on
escaped procedure invocations.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-501) Client and embedded drivers differ on invoking a procedure that returns a single Dynamic resultSet using CallableStatement.executeQuery()
[ http://issues.apache.org/jira/browse/DERBY-501?page=all ] Knut Anders Hatlen reassigned DERBY-501: Assign To: Knut Anders Hatlen Client and embedded drivers differ on invoking a procedure that returns a single Dynamic resultSet using CallableStatement.executeQuery() - Key: DERBY-501 URL: http://issues.apache.org/jira/browse/DERBY-501 Project: Derby Type: Bug Components: JDBC Versions: 10.1.1.0, 10.0.2.1 Environment: All Platforms Reporter: Satheesh Bandaram Assignee: Knut Anders Hatlen Attachments: Test.java, Test1.java It is possible to invoke a stored procedure that returns a single dynamic result using CallableStatement.executeQuery using Derby Client. The embedded JDBC driver, however, throws an exception like: Test starting ...url = jdbc:derby:tdb Exception in thread main ERROR X0Y78: Statement.executeQuery() cannot be called with a statement that returns a row count. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:301) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:434) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1142) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1323) at org.apache.derby.impl.jdbc.EmbedCallableStatement.executeStatement(EmbedCallableStatement.java:109) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(EmbedPreparedStatement.java:241) at Test1.main(Test1.java:26) I think the embedded driver behavior is incorrect here, though I would double check that the JDBC spec says. To reproduce the problem, 1) Create a database called 'tdb' and a table called COMPANY as create table COMPANY(name char(10)); 2) Insert two rows as: insert into COMPANY values 'IBM', 'SUN'; 3) register a procedure as: CREATE PROCEDURE GETALLCOMPANIES() PARAMETER STYLE JAVA LANGUAGE JAVA READS SQL DATA DYNAMIC RESULT SETS 1 EXTERNAL NAME 'Test.getAllCompanies' 4) Set server classpath 5) Compile two attached java programs, Test and Test1 6) Execute 'java Test1 1' to run as a client program and 'java Test1 2' to run as an embedded program. -- 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-178) Provide line number information in distribution's class files
[ http://issues.apache.org/jira/browse/DERBY-178?page=all ] Andrew McIntyre resolved DERBY-178: --- Fix Version: 10.2.0.0 10.1.3.0 Resolution: Fixed Derby Info: [Release Note Needed] With revisions 405655 and 405656, added targets to tools/release so that future official releases of Derby include a lib-debug distribution containing jars built with line number tables and non-optimized for easy use in debugging. Marking this Resolved. Jorg, please close this if the lib-debug distributions in the upcoming 10.1.3 release in June satisfy this requirement to your satisfaction. Thanks, andrew Provide line number information in distribution's class files - Key: DERBY-178 URL: http://issues.apache.org/jira/browse/DERBY-178 Project: Derby Type: Improvement Components: Build tools Versions: 10.0.2.2 Reporter: Jörg von Frantzius Assignee: Andrew McIntyre Priority: Minor Fix For: 10.2.0.0, 10.1.3.0 To make debugging easier using the derby distribution provided for download, it would be nice to have line numbering information included in the classes. With javac, that would be providing the option -g in the compiler's commandline. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Regression Test Failure! - TinderBox_Derby 405656 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 405656/2006-05-10 09:02:34 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 2659657 1 142.43% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-405656.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/405656.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/405656.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Commented: (DERBY-1308) Tests jdbcapi/HoldabilityTest.junit, jdbcapi/UpdateXXXTest.junit,jdbcapi/SURTest.junit fail on wctme5.7_foundation
[ http://issues.apache.org/jira/browse/DERBY-1308?page=comments#action_12378852 ] Andreas Korneliussen commented on DERBY-1308: - I think this could be a regression, since as part of DERBY-993, Myrna was able to run the following tests: With the changes in place, I can successfully run with both jdk142 and wctme5.7_foundation the following tests: junitTests/lang/LangSuite.java jdbcapi/SURTest.junit jdbcapi/SURQueryMixTest.junit jdbcapi/ConcurrencyTest.junit Tests jdbcapi/HoldabilityTest.junit, jdbcapi/UpdateXXXTest.junit,jdbcapi/SURTest.junit fail on wctme5.7_foundation -- Key: DERBY-1308 URL: http://issues.apache.org/jira/browse/DERBY-1308 Project: Derby Type: Bug Components: Test, Regression Test Failure Versions: 10.2.0.0 Environment: derby jars used - 10.2.0.0 alpha - (400220), machine is a win2000. Reporter: Sunitha Kambhampati Priority: Minor Fix For: 10.2.0.0 05/05/2006 regression test run of derbyall shows the following test failure with wctme5.7_foundation, derbyall/derbyall.fail:jdbcapi/HoldabilityTest.junit derbyall/derbyall.fail:jdbcapi/UpdateXXXTest.junit derbyall/derbyall.fail:jdbcapi/SURTest.junit Diff is a CNFE with ConnectionPoolDataSource. * Diff file derbyall/jdbcapi/HoldabilityTest.diff *** Start: HoldabilityTest jdkJ2ME Foundation Specification v1.0 derbyall:jdbcapi 2006-05-07 11:31:05 *** 0 add Exception in thread main java.lang.NoClassDefFoundError: javax.sql.ConnectionPoolDataSource Test Failed. *** End: HoldabilityTest jdkJ2ME Foundation Specification v1.0 derbyall:jdbcapi 2006-05-07 11:31:06 *** My guess is these tests need to excluded from running in this environment. Can someone please confirm. Thanks. -- 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-577) Test harness should not change the user.dir property , it is meant for infomative purpose only.
[ http://issues.apache.org/jira/browse/DERBY-577?page=all ] Myrna van Lunteren updated DERBY-577: - Attachment: DERBY-577_102_20060509.stat DERBY-577_102_20060509.diff Attached patch - DERBY-577_102_20060509.* - removes the testJvmProps.addElement(user.dir=+userDirName); line from RunTest, as well as some additional lines that set user.dir. As a result of this change, 2 tests failed - store/Beetle6038.java and tools/dblook_test.java (and derbynet/dblook_test_net.java which extends the tools one). With the change, these tests would pass when run with RunTest, but fail in a suite. I found that instead of relying on getCanonicalPath() for these tests, I had to use a full path obtained by accessing derby.system.home - property - hence the changes to dblook_test.java and Beetle6038.java. derbyall passes with this change except for: - wisconsin (looks like the known intermittent different optimizer choice) - SuicideOfStreaming (known current failure) - runtimeinfo (which fails intermittently in this 1 environment but passes elsewhere for me) Test harness should not change the user.dir property , it is meant for infomative purpose only. Key: DERBY-577 URL: http://issues.apache.org/jira/browse/DERBY-577 Project: Derby Type: Improvement Components: Test Reporter: Suresh Thalamati Assignee: Myrna van Lunteren Priority: Minor Attachments: DERBY-577_102_20060509.diff, DERBY-577_102_20060509.stat If the user.dir property is changed , you wil find IO calls are working on different directory than what is returned by File.getAbsolutePath() if the file handle is created with a relative path because of JVM issue: 4117557 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4117557 I think it is not good idea for test harness to change the user.dir property.It makes hard to debug tests , because files are not created at diferent location than what is returned by getAbsolutePath().Atleast, I had fun time figuring out this :-) user.dir is being changed at the following code segment : org.apache.derbyTesting.functionTests.harness. RunTest.java testJvmProps.addElement(user.dir=+userDirName); -- 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-1288) Bring Derby into JDBC compliance by supporting executeQuery() on escaped procedure invocations
[
http://issues.apache.org/jira/browse/DERBY-1288?page=comments#action_12378896 ]
Knut Anders Hatlen commented on DERBY-1288:
---
I wrote:
What Derby currently does, is
[...]
executeUpdate:
embedded: fails if no result sets are returned, succeeds if one or
more result sets are returned
client: succeeds regardless of how many result sets are returned,
but the return value is invalid (-1) when no result sets are
returned (it is 0 otherwise)
This wasn't correct either... :(
It should have said:
executeUpdate:
Embedded: Succeeds regardless of how many result sets are
returned. Returns 0 if no result sets are returned, -1 if one or
more result sets are returned.
Client: Succeeds and returns -1 when no result sets are
returned. Fails when one or more result sets are returned.
Bring Derby into JDBC compliance by supporting executeQuery() on escaped
procedure invocations
--
Key: DERBY-1288
URL: http://issues.apache.org/jira/browse/DERBY-1288
Project: Derby
Type: Improvement
Components: JDBC
Versions: 10.2.0.0
Reporter: Rick Hillegas
Assignee: Knut Anders Hatlen
The following statement raises an error in Derby:
statement.executeQuery( {call foo()} );
although this statement works:
statement.executeUpdate( {call foo()} );
According to section 6.4 of the latest draft of the JDBC4 Compliance chapter,
both statements are supposed to work in order to claim Java EE JDBC
Compliance.
We need to bring Derby into compliance by supporting executeQuery() on
escaped procedure invocations.
--
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-1251) cancelRowUpdates() affects rows updated with updateRow() in scrollable updatable resultsets
[ http://issues.apache.org/jira/browse/DERBY-1251?page=comments#action_12378902 ] Fernanda Pizzorno commented on DERBY-1251: -- All of my comments have been addressed. The patch DERBY-1251v3.diff looks good. cancelRowUpdates() affects rows updated with updateRow() in scrollable updatable resultsets --- Key: DERBY-1251 URL: http://issues.apache.org/jira/browse/DERBY-1251 Project: Derby Type: Bug Components: JDBC, Network Client Versions: 10.2.0.0 Reporter: Andreas Korneliussen Assignee: Andreas Korneliussen Priority: Minor Attachments: DERBY-1251.diff, DERBY-1251.stat, DERBY-1251v2.diff, DERBY-1251v2.stat, DERBY-1251v3.diff, derbyall_report.txt, derbyall_report.txt If an application does the following: rs.updateInt(1, newValueCol1); rs.updateRow(); rs.updateInt(2, newValueCol2); rs.cancelRowUpdates(); Then, when calling rs.getInt(1), it will return the old value. Instead it should return the new value. Workaround: after calling rs.updateRow(), the application could call rs.relative(0). This problem does not affect forward only resultsets, since after an updateRow() they get positoned before the next row, leaving it impossible to do anything with the current row. -- 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-1087) Updatable result sets behave different depending on the type of query used to generate the result set
[ http://issues.apache.org/jira/browse/DERBY-1087?page=all ]
Fernanda Pizzorno updated DERBY-1087:
-
Attachment: derby-1087v2.diff
derby-1087v2.stat
Patch derby-1087v2.diff addresses the review comments.
1. I changed java/engine/org/apache/derby/impl/sql/compile/FromBaseTable.java
to use a call to cursorTargetTable() method instead of using the
cursorTargetTable attribute directly. I chose not to use forUpdate() as
suggested because it is too generic.
2. Removed the test from derbynetclientmats.
3. Made 4 tests methods and added javadoc to the 4 of them.
___
Andreas wrote:
Review:
The patch looks good, here are some minor comments:
1. In java/engine/org/apache/derby/impl/sql/compile/FromBaseTable.java,
consider using a call to forUpdate() method instead of using the
cursorTargetTable attribute directly.
2. Testing: I do not think the testcase should be added to derbynetclientmats,
since it is already added to jdbcapi (it is not really a network client change)
3. Testing: Consider making 4 test methods instead of testing all variants in
the same testmethod. Now, the test fails at the first case, and I do not get to
see the results of the other variants. Also please add javadoc to all testcase
methods.
___
Updatable result sets behave different depending on the type of query used to
generate the result set
-
Key: DERBY-1087
URL: http://issues.apache.org/jira/browse/DERBY-1087
Project: Derby
Type: Bug
Components: JDBC, SQL
Reporter: Fernanda Pizzorno
Assignee: Fernanda Pizzorno
Attachments: derby-1087.diff, derby-1087.stat, derby-1087v2.diff,
derby-1087v2.stat
Running the following code with different queries in the first statement
produces different results.
Where t1 has two columns: a of type int is the primary key, and b of type
varchar(50); and contains 10 rows of data.
Statement st1 = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY,
ResultSet.CONCUR_UPDATABLE);
Statement st2 = conn.createStatement();
ResultSet rs = st1.executeQuery(SELECT a, b FROM t1);
rs.next();
rs.next();
st2.executeUpdate(UPDATE t1 SET a = a + 20 WHERE a = +
rs.getInt(1));
try {
rs.updateInt(1, rs.getInt(1) + 30);
rs.updateRow();
} catch (SQLException se) {
System.out.println(se.getMessage());
}
rs.close();
rs = st2.executeQuery(SELECT a FROM t1);
while(rs.next()) {
System.out.println(A = + rs.getInt(1));
}
rs.close();
st2.close();
st1.close();
If the first query is select a, b from t1, the output will be:
A = 1
A = 3
A = 4
A = 5
A = 6
A = 7
A = 8
A = 9
A = 10
A = 32
If the first query is SELECT a, b FROM t1 WHERE a = 5, the output will be:
Cursor 'SQLCUR0' is not on a row.
A = 1
A = 3
A = 4
A = 5
A = 6
A = 7
A = 8
A = 9
A = 10
A = 22
If the first query is SELECT a FROM t1, the output will be:
Cursor 'SQLCUR0' is not on a row.
A = 1
A = 3
A = 4
A = 5
A = 6
A = 7
A = 8
A = 9
A = 10
A = 22
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-795) After calling ResultSet.relative(0) the cursor loses its position
[ http://issues.apache.org/jira/browse/DERBY-795?page=all ]
Bernt M. Johnsen closed DERBY-795:
--
Fix Version: 10.1.3.0
Resolution: Fixed
Committed revision 405736.
After calling ResultSet.relative(0) the cursor loses its position
-
Key: DERBY-795
URL: http://issues.apache.org/jira/browse/DERBY-795
Project: Derby
Type: Bug
Components: JDBC
Versions: 10.1.2.1, 10.2.0.0
Environment: Any
Reporter: Andreas Korneliussen
Assignee: Andreas Korneliussen
Priority: Minor
Fix For: 10.2.0.0, 10.1.3.0
Attachments: DERBY-795-v2.diff, DERBY-795.diff, DERBY-795.stat
After calling rs.relative(0), on a scrollable ResultSet, the cursor looses
its position, and a rs.getXXX(..) fails with:
SQL Exception: Invalid cursor state - no current row.
Probably caused by the following logic in
ScrollInsensitiveResultSet.getRelativeRow(int row):
// Return the current row for 0
if (row == 0)
{
if ((beforeFirst || afterLast) ||
(!beforeFirst !afterLast)) {
return null;
} else {
return getRowFromHashTable(currentPosition);
}
}
The if () will always evaluate to true, regardless of the values of
beforeFirst and afterLast
Test code:
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
public class RelativeZeroIssue {
public static void main(String[] args) throws Exception {
Class.forName(org.apache.derby.jdbc.EmbeddedDriver);
Connection con =
DriverManager.getConnection(jdbc:derby:testdb2;create=true);
con.setAutoCommit(false);
try {
Statement statement = con.createStatement();
/** Create the table */
statement.execute(create table t1(id int));
statement.execute(insert into t1 values 1,2,3,4,5,6,7,8);
Statement s =
con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
ResultSet rs = s.executeQuery(select * from t1);
rs.next();
System.out.println(rs.getInt(1));
System.out.println(rs.relative(0));
System.out.println(rs.getInt(1));
} finally {
con.rollback();
con.close();
}
}
}
Output from test:
1
false
Exception in thread main SQL Exception: Invalid cursor state - no current
row.
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown
Source)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown
Source)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedConnection.newSQLException(Unknown
Source)
at org.apache.derby.impl.jdbc.ConnectionChild.newSQLException(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedResultSet.checkOnRow(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedResultSet.getColumn(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedResultSet.getInt(Unknown Source)
at derbytest.RelativeZeroIssue.main(RelativeZeroIssue.java:51)
Java Result: 1
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Regression Test Failure! - TinderBox_Derby 405696 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 405696/2006-05-10 12:03:10 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 2659657 1 141.85% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-405696.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/405696.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/405696.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Reopened: (DERBY-1058) derby fails supporting holdable scrollable resultset: ERROR XSCB8: The btree conglomerate 1,141,037,436,752 is closed.
[ http://issues.apache.org/jira/browse/DERBY-1058?page=all ] Andreas Korneliussen reopened DERBY-1058: - Reopen to see if this could go to 10.1.3 branch. If this is taken to the 10.1.3 branch, I would suggest trying to take the first diff (DERBY-1087.diff) into the 10.1.3, unless junit testing has also been taken to the 10.1.3 branch (the other diffs only has additional junit tests). derby fails supporting holdable scrollable resultset: ERROR XSCB8: The btree conglomerate 1,141,037,436,752 is closed. -- Key: DERBY-1058 URL: http://issues.apache.org/jira/browse/DERBY-1058 Project: Derby Type: Bug Components: SQL, Store Versions: 10.1.2.1, 10.2.0.0 Environment: All Reporter: Andreas Korneliussen Assignee: Andreas Korneliussen Fix For: 10.2.0.0, 10.1.3.0 Attachments: DERBY-1058.diff, DERBY-1058.stat, DERBY-1058v2.diff, DERBY-1058v2.stat, DERBY-1058v3.diff, DERBY-1058v3.stat, HoldabilityIssue.java, derbyall_report.txt If the ResultSet is so big that the scrollable resultset needs to back the hashtable to disk, and the resultset is not fully populated before a commit(), a call to next() will fail with: [EMAIL PROTECTED]:/3db-derby-10.1.2.1-bin/lib java -cp /home/ak136785/devel/derbytesting/derbytest/build/classes/:./derby.jar derbytest.HoldabilityIssue ERROR XSCB8: The btree conglomerate 1,141,037,436,752 is closed. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.access.btree.BTreeController.insert(Unknown Source) at org.apache.derby.impl.store.access.btree.index.B2IController.insert(Unknown Source) at org.apache.derby.iapi.store.access.DiskHashtable.put(Unknown Source) at org.apache.derby.iapi.store.access.BackingStoreHashtable.spillToDisk(Unknown Source) at org.apache.derby.iapi.store.access.BackingStoreHashtable.add_row_to_hash_table(Unknown Source) at org.apache.derby.iapi.store.access.BackingStoreHashtable.put(Unknown Source) at org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.addRowToHashTable(Unknown Source) at org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getNextRowFromSource(Unknown Source) at org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown Source) at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown Source) at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source) at derbytest.HoldabilityIssue.runTest1(HoldabilityIssue.java:72) at derbytest.HoldabilityIssue.main(HoldabilityIssue.java:91) [EMAIL PROTECTED]:/3db-derby-10.1.2.1-bin/lib The BtreeController is always initialized as non-holdable, and if this is changed, Derby has the following assert in closeForEndTransaction(..): SanityManager.THROWASSERT(There is currently no requirement for a held btree conglomerate controller.); A simple test program is attached which reproduces this failure. It fails in the trunk and on the 10.1.2.1 release -- 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-1058) derby fails supporting holdable scrollable resultset: ERROR XSCB8: The btree conglomerate 1,141,037,436,752 is closed.
[ http://issues.apache.org/jira/browse/DERBY-1058?page=all ] Andreas Korneliussen updated DERBY-1058: Fix Version: 10.1.3.0 derby fails supporting holdable scrollable resultset: ERROR XSCB8: The btree conglomerate 1,141,037,436,752 is closed. -- Key: DERBY-1058 URL: http://issues.apache.org/jira/browse/DERBY-1058 Project: Derby Type: Bug Components: SQL, Store Versions: 10.1.2.1, 10.2.0.0 Environment: All Reporter: Andreas Korneliussen Assignee: Andreas Korneliussen Fix For: 10.2.0.0, 10.1.3.0 Attachments: DERBY-1058.diff, DERBY-1058.stat, DERBY-1058v2.diff, DERBY-1058v2.stat, DERBY-1058v3.diff, DERBY-1058v3.stat, HoldabilityIssue.java, derbyall_report.txt If the ResultSet is so big that the scrollable resultset needs to back the hashtable to disk, and the resultset is not fully populated before a commit(), a call to next() will fail with: [EMAIL PROTECTED]:/3db-derby-10.1.2.1-bin/lib java -cp /home/ak136785/devel/derbytesting/derbytest/build/classes/:./derby.jar derbytest.HoldabilityIssue ERROR XSCB8: The btree conglomerate 1,141,037,436,752 is closed. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.access.btree.BTreeController.insert(Unknown Source) at org.apache.derby.impl.store.access.btree.index.B2IController.insert(Unknown Source) at org.apache.derby.iapi.store.access.DiskHashtable.put(Unknown Source) at org.apache.derby.iapi.store.access.BackingStoreHashtable.spillToDisk(Unknown Source) at org.apache.derby.iapi.store.access.BackingStoreHashtable.add_row_to_hash_table(Unknown Source) at org.apache.derby.iapi.store.access.BackingStoreHashtable.put(Unknown Source) at org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.addRowToHashTable(Unknown Source) at org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getNextRowFromSource(Unknown Source) at org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown Source) at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown Source) at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source) at derbytest.HoldabilityIssue.runTest1(HoldabilityIssue.java:72) at derbytest.HoldabilityIssue.main(HoldabilityIssue.java:91) [EMAIL PROTECTED]:/3db-derby-10.1.2.1-bin/lib The BtreeController is always initialized as non-holdable, and if this is changed, Derby has the following assert in closeForEndTransaction(..): SanityManager.THROWASSERT(There is currently no requirement for a held btree conglomerate controller.); A simple test program is attached which reproduces this failure. It fails in the trunk and on the 10.1.2.1 release -- 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-1303) The test of derbynet/SuicideOfStreaming.java is failed when programs are build as Insane.
[ http://issues.apache.org/jira/browse/DERBY-1303?page=comments#action_12378916 ] Tomohito Nakayama commented on DERBY-1303: -- Next are plans to solve this problem. 1) Using suite of junit, exclude SuicideOfStreaming test. Refer to. http://mail-archives.apache.org/mod_mbox/db-derby-dev/200605.mbox/44604E2D.1010503%40Sun.COM 2) In build.xml, adding derbynet/SuicideOfStreaming.java to DerbyNet.exclude if build was Insane. It seems that 1) is appropriate because test should be handled in test framework and not in build framework. The test of derbynet/SuicideOfStreaming.java is failed when programs are build as Insane. - Key: DERBY-1303 URL: http://issues.apache.org/jira/browse/DERBY-1303 Project: Derby Type: Bug Components: Test Environment: http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-405038.html Reporter: Tomohito Nakayama Assignee: Tomohito Nakayama derbynet/SuicideOfStreaming.java have dependency on build as Sane. When programs are build as Insane, code to cause artificial Exception is not compiled and streaming does not failed in derbynet/SuicideOfStreaming.java as expected in this test program. The dependency results in fail of derbynet/SuicideOfStreaming.java when programs are comiled as insane. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1313) SUR: Use DRDA's extended diagnostic to send ROW_UPDATED and ROW_DELETED warnings.
SUR: Use DRDA's extended diagnostic to send ROW_UPDATED and ROW_DELETED warnings. - Key: DERBY-1313 URL: http://issues.apache.org/jira/browse/DERBY-1313 Project: Derby Type: Bug Components: JDBC Reporter: Fernanda Pizzorno Assigned to: Fernanda Pizzorno Detectability of own changes is implemented in the client using warnings cf the write-up for DERBY-775. When a row has been deleted and/or updated, a warning will be sent to the client to indicate that fact. Presently, only one warning can be sent each time a data row is sent from to the client, that means that some warnings may be lost. Using extended diagnostic allows us to send several warnings for each data row. I propose to use extended diagnostics to send ROW_UPDATED and ROW_DELETED warnings when necessary. This may later be extended for other warnings, but I do not plan to do it as a part of the work in 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] Created: (DERBY-1314) Differences between client and embedded when invoking stored procedures using Statement.executeUpdate()
Differences between client and embedded when invoking stored procedures using Statement.executeUpdate() --- Key: DERBY-1314 URL: http://issues.apache.org/jira/browse/DERBY-1314 Project: Derby Type: Bug Components: JDBC Versions: 10.2.0.0 Reporter: Knut Anders Hatlen When invoking a stored procedure using Statement.executeUpdate(), the client driver and the embedded driver behave differently. If the stored procedure does not return any result set, the embedded driver returns 0, whereas the client returns -1. If the stored procedure returns one or more result sets, the embedded driver returns -1, whereas the client fails with an exception. -- 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-1314) Differences between client and embedded when invoking stored procedures using Statement.executeUpdate()
[ http://issues.apache.org/jira/browse/DERBY-1314?page=comments#action_12378917 ] Knut Anders Hatlen commented on DERBY-1314: --- The JDBC 3.0 javadoc for Statement.executeUpdate() says: Returns: either the row count for INSERT, UPDATE or DELETE statements, or 0 for SQL statements that return nothing Throws: SQLException - if a database access error occurs or the given SQL statement produces a ResultSet object Embedded behaves correctly when no result sets are produced by the stored procedure, and the client behaves correctly when result sets are produced. Differences between client and embedded when invoking stored procedures using Statement.executeUpdate() --- Key: DERBY-1314 URL: http://issues.apache.org/jira/browse/DERBY-1314 Project: Derby Type: Bug Components: JDBC Versions: 10.2.0.0 Reporter: Knut Anders Hatlen When invoking a stored procedure using Statement.executeUpdate(), the client driver and the embedded driver behave differently. If the stored procedure does not return any result set, the embedded driver returns 0, whereas the client returns -1. If the stored procedure returns one or more result sets, the embedded driver returns -1, whereas the client fails with an exception. -- 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-1303) The test of derbynet/SuicideOfStreaming.java is failed when programs are build as Insane.
[ http://issues.apache.org/jira/browse/DERBY-1303?page=comments#action_12378918 ] Tomohito Nakayama commented on DERBY-1303: -- One problem is that I have not written test using JUnit :( Examining past mail, I found there exists some information on Wiki. I will start from this point http://wiki.apache.org/db-derby/DerbyJUnitTesting The test of derbynet/SuicideOfStreaming.java is failed when programs are build as Insane. - Key: DERBY-1303 URL: http://issues.apache.org/jira/browse/DERBY-1303 Project: Derby Type: Bug Components: Test Environment: http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-405038.html Reporter: Tomohito Nakayama Assignee: Tomohito Nakayama derbynet/SuicideOfStreaming.java have dependency on build as Sane. When programs are build as Insane, code to cause artificial Exception is not compiled and streaming does not failed in derbynet/SuicideOfStreaming.java as expected in this test program. The dependency results in fail of derbynet/SuicideOfStreaming.java when programs are comiled as insane. -- 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
[Fwd: [jira] Commented: (DERBY-1303) The test of derbynet/SuicideOfStreaming.java is failed when programs are build as Insane.]
Hello Tomohito, Hope it's okay I send you a private mail. I just want to tell you that the Wiki page has not been used/follow by many, and I would appreciate if you gave some feedback (to the list) on what is missing on it. What information did you not find that was necessary for you to write your JUnit test? I will try to add new content as people request it. If you ask JUnit questions on the list I will pay extra and try to help out (but I am going to JavaOne in USA on Friday, so I might not be able to read mail as often as usual). regards, -- Kristian ---BeginMessage--- [ http://issues.apache.org/jira/browse/DERBY-1303?page=comments#action_12378918 ] Tomohito Nakayama commented on DERBY-1303: -- One problem is that I have not written test using JUnit :( Examining past mail, I found there exists some information on Wiki. I will start from this point http://wiki.apache.org/db-derby/DerbyJUnitTesting The test of derbynet/SuicideOfStreaming.java is failed when programs are build as Insane. - Key: DERBY-1303 URL: http://issues.apache.org/jira/browse/DERBY-1303 Project: Derby Type: Bug Components: Test Environment: http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-405038.html Reporter: Tomohito Nakayama Assignee: Tomohito Nakayama derbynet/SuicideOfStreaming.java have dependency on build as Sane. When programs are build as Insane, code to cause artificial Exception is not compiled and streaming does not failed in derbynet/SuicideOfStreaming.java as expected in this test program. The dependency results in fail of derbynet/SuicideOfStreaming.java when programs are comiled as insane. -- 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 ---End Message---
[jira] Commented: (DERBY-1251) cancelRowUpdates() affects rows updated with updateRow() in scrollable updatable resultsets
[ http://issues.apache.org/jira/browse/DERBY-1251?page=comments#action_12378922 ] Knut Anders Hatlen commented on DERBY-1251: --- I will run some tests and commit the patch. cancelRowUpdates() affects rows updated with updateRow() in scrollable updatable resultsets --- Key: DERBY-1251 URL: http://issues.apache.org/jira/browse/DERBY-1251 Project: Derby Type: Bug Components: JDBC, Network Client Versions: 10.2.0.0 Reporter: Andreas Korneliussen Assignee: Andreas Korneliussen Priority: Minor Attachments: DERBY-1251.diff, DERBY-1251.stat, DERBY-1251v2.diff, DERBY-1251v2.stat, DERBY-1251v3.diff, derbyall_report.txt, derbyall_report.txt If an application does the following: rs.updateInt(1, newValueCol1); rs.updateRow(); rs.updateInt(2, newValueCol2); rs.cancelRowUpdates(); Then, when calling rs.getInt(1), it will return the old value. Instead it should return the new value. Workaround: after calling rs.updateRow(), the application could call rs.relative(0). This problem does not affect forward only resultsets, since after an updateRow() they get positoned before the next row, leaving it impossible to do anything with the current row. -- 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-717) update doc on updatable cursors
[ http://issues.apache.org/jira/browse/DERBY-717?page=all ] Andreas Korneliussen updated DERBY-717: --- Attachment: DERBY-717v3.diff DERBY-717v3.stat derby-717v3.tar.gz The attached files (DERBY-717v3.*) now also contains updates to the Derby reference manual w.r.t. the updatable cursor features. Also changed some minor issues found in the first diff. update doc on updatable cursors --- Key: DERBY-717 URL: http://issues.apache.org/jira/browse/DERBY-717 Project: Derby Type: Improvement Components: Documentation Versions: 10.2.0.0 Reporter: Andreas Korneliussen Assignee: Andreas Korneliussen Priority: Minor Attachments: DERBY-717.diff, DERBY-717.stat, DERBY-717v2.diff, DERBY-717v3.diff, DERBY-717v3.stat, derby-717.tar.gz, derby-717v3.tar.gz The new features introduced in DERBY-690, DERBY-231, DERBY-775 and DERBY-100 should be documented in the Derby developer guide. This includes: * updatable cursors do longer need to FOR UPDATE clause * Scrollable insensitive resultsets can be updatable * ResultSet.insertRow() -- 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: 10.1.2.4 snapshot posted
Andrew McIntyre wrote: Hi derby-dev and derby-user, I have just posted a new snapshot for 10.1 as we are heading towards a 10.1.3.0 release: Thanks Andrew, I like the additional text you added with the link to the issues and suggested areas to test. However, I think when a snapshot is posted we should leave the older snapshots on the download page. Makes it much easier for people to demonstrate a regression if they can easily show it's in the latest snapshot but not the previous snapshot. Maybe the snapshots should only be removed once an official release is made on the branch for the snapshots. Thoughts? Thanks, Dan.
[jira] Commented: (DERBY-1276) Calling ResultSet.isLast() on a scrollable insensitive resultset, causes the entire ResultSet to be populated
[ http://issues.apache.org/jira/browse/DERBY-1276?page=comments#action_12378930 ] Dag H. Wanvik commented on DERBY-1276: -- I looked at this and it looks good to me. It seems you also optimized the case where the last row has not yet been read and the cursor has moved back (in which case no positioning is needed to affirm we are not on last row: currentPositionpositionInSource); good! You don't mention what tests have been run, if any. If derbyall runs OK, I'd say this is ready to go. Calling ResultSet.isLast() on a scrollable insensitive resultset, causes the entire ResultSet to be populated - Key: DERBY-1276 URL: http://issues.apache.org/jira/browse/DERBY-1276 Project: Derby Type: Improvement Components: SQL Versions: 10.2.0.0, 10.1.3.0 Reporter: Andreas Korneliussen Assignee: Andreas Korneliussen Priority: Minor Attachments: DERBY-1276.diff, DERBY-1276.stat The following is not a bug, however some applications do not always need to scroll to the last row, however they do want to check isLast(). Therefore it is unfortunate that isLast() is expensive. The general logic in ScrollInsensitiveResultSet is to populate rows by demand. The current logic in ScrollInsensitiveResultSet to return true or false on isLast(), is to move to the last row. If the last row is not the same row number as the current, then isLast() returns false. When moving to the last row, all rows will be populated into the BackingStoreHashtable of the ScrollInsensitiveResultSet. This logic may be rewritten to only move to the next row. If the next row exists, isLast() may return false. (note the logic is also optimized to use beforeFirst and afterLast flags) -- 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-1276) Calling ResultSet.isLast() on a scrollable insensitive resultset, causes the entire ResultSet to be populated
[ http://issues.apache.org/jira/browse/DERBY-1276?page=comments#action_12378932 ] Andreas Korneliussen commented on DERBY-1276: - Yes, I ran derbyall with this change. Found that * derbyall/derbynetmats/derbynetmats.fail:stress/stress.multi failed. I do not think the failure is related to the patch (ran the test with priority nice, it could possibly have influenced the test run). I will rerun the tests. Calling ResultSet.isLast() on a scrollable insensitive resultset, causes the entire ResultSet to be populated - Key: DERBY-1276 URL: http://issues.apache.org/jira/browse/DERBY-1276 Project: Derby Type: Improvement Components: SQL Versions: 10.2.0.0, 10.1.3.0 Reporter: Andreas Korneliussen Assignee: Andreas Korneliussen Priority: Minor Attachments: DERBY-1276.diff, DERBY-1276.stat The following is not a bug, however some applications do not always need to scroll to the last row, however they do want to check isLast(). Therefore it is unfortunate that isLast() is expensive. The general logic in ScrollInsensitiveResultSet is to populate rows by demand. The current logic in ScrollInsensitiveResultSet to return true or false on isLast(), is to move to the last row. If the last row is not the same row number as the current, then isLast() returns false. When moving to the last row, all rows will be populated into the BackingStoreHashtable of the ScrollInsensitiveResultSet. This logic may be rewritten to only move to the next row. If the next row exists, isLast() may return false. (note the logic is also optimized to use beforeFirst and afterLast flags) -- 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: 10.1.2.4 snapshot posted
On 5/10/06, Daniel John Debrunner [EMAIL PROTECTED] wrote: However, I think when a snapshot is posted we should leave the older snapshots on the download page. Makes it much easier for people to demonstrate a regression if they can easily show it's in the latest snapshot but not the previous snapshot. Maybe the snapshots should only be removed once an official release is made on the branch for the snapshots. Thoughts? I was thinking it would be sufficient to compare with the last official release, but I agree that at least a couple of snapshots of history would be nice. I'll make a note of it on the SnapshotAndRelease page, and I'll make sure to leave this one up next time. Just want to note that you can still get the older ones from svn if you need them, also. andrew
Re: Developer access to Jira
On 5/10/06, Vemund Ostgaard [EMAIL PROTECTED] wrote: I would like to be granted developer access to Jira. It seems I need this to be able to close a bug I reported. Granted. andrew
Feedback integrate/plugin_howto.html
Dear Derby-Dev, Regarding your article Using the 10.1 Core and 1.1 UI Derby plug-ins at URL http://db.apache.org/derby/integrate/plugin_howto.html#Installing+the+plug-i ns I have tried to install the Derby plugins twice now, without success. I checked the md5 sums for both derby_core_plugin_10.1.2.zip and derby_ui_plugin_1.1.0.zip. They were both OK. I unzipped them both into C:\eclipse, my ECLIPSE_HOME, as a result there are 3 new subdirectories under C:\eclipse\plugins: org.apache.derby.core_10.1.2 org.apache.derby.plugin.doc_1.1.0 org.apache.derby.ui_1.1.0 However, after restarting eclipse, Version: 3.1.2, Build id: M20060118-1600, Apache Derby does NOT show up in the menu when I right-click on my project. Additionally, under HelpAbout Eclipse SDKPlug-in Details, when I sort on Plug-in Id, org.apache.axis is followed by org.apache.lucene and NOT by org.apache.derby.core and the 2 other derby items, as I expected. I hope you can help me. If you want, I can provide a listing of the directory contents of the derby plugins, as well as a listing of the relevant plugin.xmls. Thanks in advance. Regards, Joe Dorocak [EMAIL PROTECTED]
[jira] Commented: (DERBY-1219) jdbcapi/checkDataSource.java and jdbcapi/checkDataSource30.java hang intermittently with client
[ http://issues.apache.org/jira/browse/DERBY-1219?page=comments#action_12378938 ] Deepa Remesh commented on DERBY-1219: - Hi Bryan, I applied your new patch 'no-sessions-for-closed-threads.diff' and ran the checkDataSource repro. However, I still get the hang intermittently on my machine. Though the hang has not gone away, I think the scenario you explain is a probable one. And as you said, the bug is quite interesting as it can have many possible scenarios. jdbcapi/checkDataSource.java and jdbcapi/checkDataSource30.java hang intermittently with client --- Key: DERBY-1219 URL: http://issues.apache.org/jira/browse/DERBY-1219 Project: Derby Type: Test Components: Network Server, Network Client Versions: 10.2.0.0 Environment: More often on jdk 1.5 or jdk 1.6 but hangs on jdk 1.4.2 as well Reporter: Kathey Marsden Assignee: Bryan Pendleton Priority: Minor Attachments: client_stack_trace_050306.txt, drda_traces_050206.zip, interrupt.diff, no-sessions-for-closed-threads.diff, server_stack_trace_050306.txt, skipThreads.diff, testfiles_afterhang.zip, traces_on_hang.txt The tests checkDataSource.java and checkDataSource30.java hang intermittently especially with jdk 1.5. Attached is the test run output and traces when the server is started separately. 1) Enable checkDataSource30.java by taking it out of functionTests/suites/DerbyNetClient.exclude. 2) Run the test with client. java -Dij.exceptionTrace=true -Dkeepfiles=true -Dframework=DerbyNetClient org.apache.derbyTesting.functionTests.harness.RunTest jdbcapi/checkDataSource30.java Attachements: testfiles_after_hang.zip - Test directory. traces_on_hang.txt - Server side traces obtained by starting the server separately before running the test. I wish I had time to work on this right now as I would really like to see this valuable test in the suite, but hopefully someone else will pick it up. -- 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-1219) jdbcapi/checkDataSource.java and jdbcapi/checkDataSource30.java hang intermittently with client
[ http://issues.apache.org/jira/browse/DERBY-1219?page=comments#action_12378954 ] Deepa Remesh commented on DERBY-1219: - Posting my observation with the patch 'no-sessions-for-closed-threads.diff': I think this patch solves the problem of poisoned threads partially. It makes sure that a thread which has been marked closed does not get a session to work on. However, the session which came in is still hanging because there are no new threads which can pick it up. When the session came in, server had queued it so that a free thread picks it up. But the thread which picked it up was a poisoned (closed) thread. So the session is still waiting for another thread. To test that the hang will go away when a new thread gets created, I opened another connection using ij. This made the hang go away and the repro ran to the end. When the connection from ij came in, the newly created thread was able to work on the waiting session and resolve the hang. Bryan, I am looking at your trial patch interrupt.diff which looks like a good solution to me too. This patch made the hang go away on my machine. But you had said that it did not resolve all hangs for you. Can you please post your observations with this patch? jdbcapi/checkDataSource.java and jdbcapi/checkDataSource30.java hang intermittently with client --- Key: DERBY-1219 URL: http://issues.apache.org/jira/browse/DERBY-1219 Project: Derby Type: Test Components: Network Server, Network Client Versions: 10.2.0.0 Environment: More often on jdk 1.5 or jdk 1.6 but hangs on jdk 1.4.2 as well Reporter: Kathey Marsden Assignee: Bryan Pendleton Priority: Minor Attachments: client_stack_trace_050306.txt, drda_traces_050206.zip, interrupt.diff, no-sessions-for-closed-threads.diff, server_stack_trace_050306.txt, skipThreads.diff, testfiles_afterhang.zip, traces_on_hang.txt The tests checkDataSource.java and checkDataSource30.java hang intermittently especially with jdk 1.5. Attached is the test run output and traces when the server is started separately. 1) Enable checkDataSource30.java by taking it out of functionTests/suites/DerbyNetClient.exclude. 2) Run the test with client. java -Dij.exceptionTrace=true -Dkeepfiles=true -Dframework=DerbyNetClient org.apache.derbyTesting.functionTests.harness.RunTest jdbcapi/checkDataSource30.java Attachements: testfiles_after_hang.zip - Test directory. traces_on_hang.txt - Server side traces obtained by starting the server separately before running the test. I wish I had time to work on this right now as I would really like to see this valuable test in the suite, but hopefully someone else will pick it up. -- 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
Adding upgrade suite to the nightly regression tests
It would be good if we can get the upgrade suite to run individually in the nightly tests. This suite is not made part of derbyall as it currently runs only with jar files. To run this suite, some changes may be needed in the test scripts. This is described in BUILDING.txt and testing/README.htm files. It would also be good to get feedback if these instructions are not clear. Thanks, Deepa
[jira] Commented: (DERBY-1153) derbynet/SqlExceptionTest.junit fails with Sun JDK 1.3
[ http://issues.apache.org/jira/browse/DERBY-1153?page=comments#action_12378963 ] Sunitha Kambhampati commented on DERBY-1153: This tests also fails with ibm 1.3.1 version apart from sun 1.3.1 jvm. with same diff . derbynet/SqlExceptionTest.junit fails with Sun JDK 1.3 -- Key: DERBY-1153 URL: http://issues.apache.org/jira/browse/DERBY-1153 Project: Derby Type: Bug Components: Regression Test Failure, Test Versions: 10.2.0.0 Reporter: A B Priority: Minor derbynet/SqlExceptionTest.junit fails with Sun JDK 1.3: 0 add .E.E There were 2 errors: 1) testChainedException(org.apache.derbyTesting.functionTests.tests.derbynet.SqlExceptionTest)java.lang.NoSuchMethodError 2) testNextException(org.apache.derbyTesting.functionTests.tests.derbynet.SqlExceptionTest)java.lang.NoSuchMethodError FAILURES!!! Tests run: 2, Failures: 0, Errors: 2 The test passes with 1.4.2, so this looks like a master update 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-1153) derbynet/SqlExceptionTest.junit fails with Sun JDK 1.3
[ http://issues.apache.org/jira/browse/DERBY-1153?page=all ] Sunitha Kambhampati updated DERBY-1153: --- Component: Test derbynet/SqlExceptionTest.junit fails with Sun JDK 1.3 -- Key: DERBY-1153 URL: http://issues.apache.org/jira/browse/DERBY-1153 Project: Derby Type: Bug Components: Regression Test Failure, Test Versions: 10.2.0.0 Reporter: A B Priority: Minor derbynet/SqlExceptionTest.junit fails with Sun JDK 1.3: 0 add .E.E There were 2 errors: 1) testChainedException(org.apache.derbyTesting.functionTests.tests.derbynet.SqlExceptionTest)java.lang.NoSuchMethodError 2) testNextException(org.apache.derbyTesting.functionTests.tests.derbynet.SqlExceptionTest)java.lang.NoSuchMethodError FAILURES!!! Tests run: 2, Failures: 0, Errors: 2 The test passes with 1.4.2, so this looks like a master update 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-1219) jdbcapi/checkDataSource.java and jdbcapi/checkDataSource30.java hang intermittently with client
[ http://issues.apache.org/jira/browse/DERBY-1219?page=comments#action_12378971 ] Bryan Pendleton commented on DERBY-1219: I will gladly work on interrupt.diff some more, and try to provide more testing details. But I won't get to it until at least this weekend, sorry. Thanks very much for continuing to work on this with me; I think we're making some real progress here! jdbcapi/checkDataSource.java and jdbcapi/checkDataSource30.java hang intermittently with client --- Key: DERBY-1219 URL: http://issues.apache.org/jira/browse/DERBY-1219 Project: Derby Type: Test Components: Network Server, Network Client Versions: 10.2.0.0 Environment: More often on jdk 1.5 or jdk 1.6 but hangs on jdk 1.4.2 as well Reporter: Kathey Marsden Assignee: Bryan Pendleton Priority: Minor Attachments: client_stack_trace_050306.txt, drda_traces_050206.zip, interrupt.diff, no-sessions-for-closed-threads.diff, server_stack_trace_050306.txt, skipThreads.diff, testfiles_afterhang.zip, traces_on_hang.txt The tests checkDataSource.java and checkDataSource30.java hang intermittently especially with jdk 1.5. Attached is the test run output and traces when the server is started separately. 1) Enable checkDataSource30.java by taking it out of functionTests/suites/DerbyNetClient.exclude. 2) Run the test with client. java -Dij.exceptionTrace=true -Dkeepfiles=true -Dframework=DerbyNetClient org.apache.derbyTesting.functionTests.harness.RunTest jdbcapi/checkDataSource30.java Attachements: testfiles_after_hang.zip - Test directory. traces_on_hang.txt - Server side traces obtained by starting the server separately before running the test. I wish I had time to work on this right now as I would really like to see this valuable test in the suite, but hopefully someone else will pick it up. -- 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
www back up, svn still down
For those of you wondering ... The machine that hosts www and subversion is having problems. Infra volunteers have redirected www to another machine, so web access is back. Infra is working on svn and I don't know how long this will take -- please be patient. -jean
[jira] Commented: (DERBY-1256) Remove usage of non-portable methods in derby code
[ http://issues.apache.org/jira/browse/DERBY-1256?page=comments#action_12378980 ] Daniel John Debrunner commented on DERBY-1256: -- The complete class StringBufferInputStream is also non-portable and deprecated. It's used in ClobOutputStream though fixing DERBY-684 might remove its use. Remove usage of non-portable methods in derby code -- Key: DERBY-1256 URL: http://issues.apache.org/jira/browse/DERBY-1256 Project: Derby Type: Bug Components: SQL, Network Server, Store, Test Reporter: Sunitha Kambhampati Fix For: 10.2.0.0 Remove usage of non portable methods that use native encoding as they could potentially lead to bugs on platforms with different encodings. Replace with code using fixed conversion, or alternative mechanisms. If the call is required its use should be commented as to why it is required. I went through the classes in java.io package in jdk1.4.2 and have come up with a list of methods, constructors in the java.io.* classes that use native encoding and did a java search on eclipse for the code in java/engine, java/testing, java/drda, java/client. 1)ByteArrayOutputStream.toString() testing - DerbyNetNewServer: System.out.println( bos.toString()); server- NetworkServerCtrlInfo.getCLSSysInfo, getNetSysInfo, 2)DataInputStream.readLine() ArrayInputStream - org.apache.derby.iapi.services.io - java/engine readLine() CorruptRandomAccessFile - org.apache.derbyTesting.functionTests.util.corruptio - java/testing readLine() 3)InputStreamReader(InputStream) StatementDuration - org.apache.derby.diag - java/engine - next() ImportReadData - org.apache.derby.impl.load - java/engine - realOpenFile() ErrorLogReader - org.apache.derby.diag - java/engine - next() UCode_CharStream - org.apache.derby.impl.sql.compile - java/engine - ReInit(InputStream, int, int, int) xmlBinding - org.apache.derbyTesting.functionTests.tests.lang - java/testing - insertDocWithDTD(Connection, String, String, String, int) BaseMonitor - org.apache.derby.impl.services.monitor - java/engine - dumpTempWriter(boolean) DbFile - org.apache.derbyTesting.functionTests.util - java/testing - stringFromFile(InputStream) HandleResult - org.apache.derbyTesting.functionTests.harness - java/testing - handleResult(int, InputStream, InputStream, PrintWriter, String) (2 matches) ProcessStreamResult - org.apache.derbyTesting.functionTests.harness - java/testing - run() FileCompare - org.apache.derbyTesting.functionTests.harness - java/testing - doSysDiff(InputStream, String, String, File, PrintWriter) exec(String, File, PrintWriter, String, String, String, int, boolean, boolean, String, String, String) UCode_CharStream(InputStream, int, int, int) insertFiles(Connection, String, String, int) (2 matches) 4) OuputStreamWriter(OutputStream) ExportWriteData - org.apache.derby.impl.load - java/engine openFile() ProcessStreamResult - org.apache.derbyTesting.functionTests.harness - java/testing ProcessStreamResult(InputStream, BufferedOutputStream, String, String) RawStore - org.apache.derby.impl.store.raw - java/engine run() 5) RandomAccessFile.readLine() ArrayInputStream - org.apache.derby.iapi.services.io - java/engine - readLine() CorruptRandomAccessFile - org.apache.derbyTesting.functionTests.util.corruptio - java/testing - readLine() DerbyNetAutoStart - org.apache.derbyTesting.functionTests.tests.derbynet - java/testing - checkLog(RandomAccessFile, String[]) PrintStream and PrintWriter , print methods uses platforms default charset encoding. = There are also non portable methods in String class new String(byte[]) new String(byte[],int,int) String.getBytes(). There are jira entries already for these- DERBY-900, DERBY-901,DERBY-902,DERBY-903. -- 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-216) expand largeCodeGen.java test
Kathey, I ran the lang/largeCodeGen.java with PRINT_FAILURE_EXCEPTIONset to true as follows: java -Dverbose=true -Djvmflags=-mx512M -ms512M -Dframework=DerbyNetClientorg.apache.derbyTesting.functionTests.harness.RunTest lang/largeCodeGen.java and got the following MasterFileName = master/largeCodeGen.out15a16,18 java.sql.SQLException: Statement too complex. Try rewriting the query to remove complexity. Eliminating many duplicate expressions or breaking up the query and storing interim results in a temporary table can often help resolve this error . SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:e1 code_length (65577 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203axd010x50a9065e9. Caused by: org.apache.derby.client.am.SqlException: Statement too complex. Tryrewriting the query to remove complexity. Eliminating many duplicate expressions or breaking up the query and storing interim results in a temporary table can often help resolve this error. SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:e1 code_length (65577 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203axd010x50a9065e9. ... 4 more19 del PASS: IN clause with 97000 parameters20 del PASS: PREPARE: IN clause with 98000 parameters21 del PASS: IN clause with 98000 parameters22 delbrawny src/NightlyBuildResults.2006-05-10 lschanges.txt ibm142_largeData test.txt update.txtbrawny src/NightlyBuildResults.2006-05-10 tail -f test.txt 27a35,37 java.sql.SQLException: Statement too complex. Try rewriting the query to remove complexity. Eliminating many duplicate expressions or breaking up the query and storing interim results in a temporary table can often help resolve this error . SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:fillResultSet code_length (69127 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203axd010x50a9065e11. Caused by: org.apache.derby.client.am.SqlException: Statement too complex. Tryrewriting the query to remove complexity. Eliminating many duplicate _expression_s or breaking up the query and storing interim results in a temporary table can often help resolve this error. SQLSTATE: XBCM4: Java class file format limit(s)exceeded: method:fillResultSet code_length (69127 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203axd010x50a9065e11. ... 3 more28 add java.sql.SQLException: Java exception: ': java.lang.OutOfMemoryError'. Caused by: org.apache.derby.client.am.SqlException : Java exception: ': java.lang.OutOfMemoryError'. ... 3 moreTest Failed.Thanks, Raman On 5/5/06, Kathey Marsden (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-216?page=comments#action_12378176 ]Kathey Marsden commented on DERBY-216:--With revision 37644 I fixed the run to run differences and at that time the test passed with both embedded and client on Windows.I never tried on Linux. With revision 377609 Dan was able to move the number of parameters in the in list query from 3400 to 97000 (amazing). I don't know if it passed with client at that time.Raman's testing shows that client fails before 97000 with client. Ramanwhat is the highest number it goes to with client and what is the error and stack trace when it fails? In the test there is aboolean PRINT_FAILURE_EXCEPTIONthat you will have to change to see the failure. expand largeCodeGen.java test -Key: DERBY-216URL: http://issues.apache.org/jira/browse/DERBY-216 Project: Derby Type: Sub-task Components: Test Reporter: Kathey Marsden the largeCodeGen test needs to be expanded to include other cases that genreate large amounts of byte code. For example:large in clauselarge insert statement that inserts many rowssql statements with large constant values It is best if the verious tests just use a variable that can be bumped higher and higher for testing and if individual cases are isolated. Possible approaches, think of ways to make sql statements really big that will take different code paths. Look in the code for instances of statementNumHitLimit and create cases that pass through that code.Those cases may pass but the hope is to get rid of these calls in favor of splittingthe code in a centralized way, so add the tests to largeCodeGen even if they don't fail. --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 -- Ramandeep Kaur[EMAIL PROTECTED]
[jira] Commented: (DERBY-684) Improve performance of Clob objects (ClobOutputStream#write,ClobWriter#write) on the client
[ http://issues.apache.org/jira/browse/DERBY-684?page=comments#action_12378981 ] Daniel John Debrunner commented on DERBY-684: - Note that StringBufferInputStream is non-portable and should not be used. It will lead to different output on platforms with different default encoding, e.g. IBM z/os. See DERBY-1256 Improve performance of Clob objects (ClobOutputStream#write,ClobWriter#write) on the client --- Key: DERBY-684 URL: http://issues.apache.org/jira/browse/DERBY-684 Project: Derby Type: Improvement Components: Performance, Network Client Versions: 10.2.0.0, 10.1.1.1, 10.1.1.0 Environment: all Reporter: Sunitha Kambhampati Dan suggested this improvement here: http://issues.apache.org/jira/browse/DERBY-463?page=comments#action_12356742 For org.apache.derby.client.am.ClobOutputStream#write(int), five objects are created for every byte written. In fact this class and the client Clob have code like this everywhere, as the Clob is updated: clob_.string_ = clob_.string_.concat(new String(newByte)); clob_.asciiStream_ = new java.io.StringBufferInputStream(clob_.string_); clob_.unicodeStream_ = new java.io.StringBufferInputStream(clob_.string_); clob_.characterStream_ = new java.io.StringReader(clob_.string_); Would probably be better to create most of those objects on demand, rather than on every modification. I mean if the CLOB is modified but the application never retrieives the ascii or character streams, what was the benefit of creating them? Also check the org.apache.derby.client.am.ClobWriter. Need to make this better and efficient. -- 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-216) expand largeCodeGen.java test
Kathey, please ignore previous stack trace. I am writing it here again:- MasterFileName = master/largeCodeGen.out15a16,18 java.sql.SQLException: Statement too complex. Try rewriting the query to remove complexity. Eliminating many duplicate expressions or breaking up the query and storing interim results in a temporary table can often help resolve this error. SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:e1 code_length (65577 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203ax d010x50a9065e9. Caused by: org.apache.derby.client.am.SqlException: Statement too complex. Tryrewriting the query to remove complexity. Eliminating many duplicate _expression_s or breaking up the query and storing interim results in a temporary table can often help resolve this error. SQLSTATE: XBCM4: Java class file format limit(s)exceeded: method:e1 code_length (65577 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203axd010x50a9065e9 . ... 4 more19 del PASS: IN clause with 97000 parameters20 del PASS: PREPARE: IN clause with 98000 parameters21 del PASS: IN clause with 98000 parameters22 del FAILED QUERY: IN clause with 99000 parameters. 22a22,29 FAILED QUERY: IN clause with 97000 parameters. java.sql.SQLException: The parameter position '31,465' is out of range. The number of parameters for this prepared statement is '31,464'. at org.apache.derby.client.am.PreparedStatement.setInt(PreparedStatement.java(Compiled Code)) Caused by: org.apache.derby.client.am.SqlException: The parameter position '31,465' is out of range. The number of parameters for this prepared statement is '31,464'. at org.apache.derby.client.am.PreparedStatement.checkForValidParameterIndex(PreparedStatement.java(Compiled Code)) at org.apache.derby.client.am.PreparedStatement.checkSetterPreconditions (PreparedStatement.java(Inlined Compiled Code)) at org.apache.derby.client.am.PreparedStatement.setIntX(PreparedStatement.java(Inlined Compiled Code)) ... 5 more27a35,37 java.sql.SQLException : Statement too complex. Try rewriting the query to remove complexity. Eliminating many duplicate expressions or breaking up the query and storing interim results in a temporary table can often help resolve this error . SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:fillResultSet code_length (69127 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203axd010x50a9065e11. Caused by: org.apache.derby.client.am.SqlException: Statement too complex. Tryrewriting the query to remove complexity. Eliminating many duplicate _expression_s or breaking up the query and storing interim results in a temporary table can often help resolve this error. SQLSTATE: XBCM4: Java class file format limit(s)exceeded: method:fillResultSet code_length (69127 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203axd010x50a9065e11 . ... 3 more28 add java.sql.SQLException: Java exception: ': java.lang.OutOfMemoryError'. Caused by: org.apache.derby.client.am.SqlException: Java exception: ': java.lang.OutOfMemoryError '. ... 3 moreTest Failed. On 5/10/06, Ramandeep Kaur [EMAIL PROTECTED] wrote: Kathey, I ran the lang/largeCodeGen.java with PRINT_FAILURE_EXCEPTIONset to true as follows: java -Dverbose=true -Djvmflags=-mx512M -ms512M -Dframework=DerbyNetClientorg.apache.derbyTesting.functionTests.harness.RunTest lang/largeCodeGen.java and got the following MasterFileName = master/largeCodeGen.out15a16,18 java.sql.SQLException: Statement too complex. Try rewriting the query to remove complexity. Eliminating many duplicate expressions or breaking up the query and storing interim results in a temporary table can often help resolve this error . SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:e1 code_length (65577 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203axd010x50a9065e9. Caused by: org.apache.derby.client.am.SqlException: Statement too complex. Tryrewriting the query to remove complexity. Eliminating many duplicate expressions or breaking up the query and storing interim results in a temporary table can often help resolve this error. SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:e1 code_length (65577 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203axd010x50a9065e9. ... 4 more19 del PASS: IN clause with 97000 parameters20 del PASS: PREPARE: IN clause with 98000 parameters21 del PASS: IN clause with 98000 parameters22 delbrawny src/NightlyBuildResults.2006-05-10 lschanges.txt ibm142_largeData test.txt update.txtbrawny src/NightlyBuildResults.2006-05-10 tail -f test.txt 27a35,37 java.sql.SQLException: Statement too complex. Try rewriting the query to remove complexity. Eliminating many duplicate expressions or breaking up the query and storing interim results in a temporary table can often help resolve this error . SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:fillResultSet code_length
Re: [jira] Commented: (DERBY-216) expand largeCodeGen.java test
Attaching files. Thanks, Raman largeCodeGen.out Description: Binary data PASS: PREPARE: Logical operators with 200 parameters PASS: Logical operators with 200 parameters PASS: PREPARE: Logical operators with 300 parameters PASS: Logical operators with 300 parameters PASS: PREPARE: Logical operators with 400 parameters PASS: Logical operators with 400 parameters PASS: PREPARE: Logical operators with 500 parameters PASS: Logical operators with 500 parameters PASS: PREPARE: Logical operators with 600 parameters PASS: Logical operators with 600 parameters PASS: PREPARE: Logical operators with 700 parameters PASS: Logical operators with 700 parameters PASS: PREPARE: Logical operators with 800 parameters PASS: Logical operators with 800 parameters FAILED QUERY: Logical operators with 900 parameters. PASS: PREPARE: IN clause with 3400 parameters PASS: IN clause with 3400 parameters PASS: PREPARE: IN clause with 97000 parameters PASS: IN clause with 97000 parameters PASS: PREPARE: IN clause with 98000 parameters PASS: IN clause with 98000 parameters FAILED QUERY: IN clause with 99000 parameters. PASS: PREPARE: SELECT with 800 unions PASS: EXECUTE SELECT with 800 unions Row data check ok PASS: PREPARE: SELECT with 900 unions PASS: EXECUTE SELECT with 900 unions Row data check ok FAILED QUERY: SELECT with 1000 unions. FAILED QUERY: SELECT with 1 unions. largeCodeGen.diff Description: Binary data largeCodeGen.fail Description: Binary data largeCodeGen.tmp Description: Binary data
[jira] Created: (DERBY-1315) largeCodeGen fails with framework DerbyNetClient
largeCodeGen fails with framework DerbyNetClient Key: DERBY-1315 URL: http://issues.apache.org/jira/browse/DERBY-1315 Project: Derby Type: Bug Components: Test Versions: 10.2.0.0 Environment: Linux - Suse 2.6.5-7.252 Reporter: Ramandeep Kaur Priority: Blocker The test case lang/largeCodeGen.java was run as is without giving any -Djvmflags=-mx512M -ms512M and gave the following error: *** Start: largeCodeGen jdk1.4.2 largeDataTests:largeDataTests 2006-04-29 08:30:04 *** 27a28 JVMST109: Insufficient space in Javaheap to satisfy allocation request Test Failed. *** End: largeCodeGen jdk1.4.2 largeDataTests:largeDataTests 2006-04-29 08:32:01 *** Then the test case lang/largeCodeGen.java was run with -Djvmflags=-mx512M -ms512M, and it gave the following error: PASS: IN clause with 97000 parameters 20 del PASS: PREPARE: IN clause with 98000 parameters 21 del PASS: IN clause with 98000 parameters 22 del FAILED QUERY: IN clause with 99000 parameters. 22a19 FAILED QUERY: IN clause with 97000 parameters. Test Failed. Then I modified test case lang/largeCodeGen.java to set PRINT_FAILURE_EXCEPTION to true and ran the test again. This time I got the following error and stack trace: MasterFileName = master/largeCodeGen.out 15a16,18 java.sql.SQLException: Statement too complex. Try rewriting the query to remove complexity. Eliminating many duplicate expressions or breaking up the query and storing interim results in a temporary table can often help resolve this error . SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:e1 code_leng th (65577 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203ax d010x50a9065e9. Caused by: org.apache.derby.client.am.SqlException: Statement too complex. Try rewriting the query to remove complexity. Eliminating many duplicate expression s or breaking up the query and storing interim results in a temporary table can often help resolve this error. SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:e1 code_length (65577 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203axd010x50a9065e9 . ... 4 more 19 del PASS: IN clause with 97000 parameters 20 del PASS: PREPARE: IN clause with 98000 parameters 21 del PASS: IN clause with 98000 parameters 22 del FAILED QUERY: IN clause with 99000 parameters. 22a22,29 FAILED QUERY: IN clause with 97000 parameters. java.sql.SQLException: The parameter position '31,465' is out of range. The number of parameters for this prepared statement is '31,464'. at org.apache.derby.client.am.PreparedStatement.setInt(PreparedStatement .java(Compiled Code)) Caused by: org.apache.derby.client.am.SqlException: The parameter position '31 ,465' is out of range. The number of parameters for this prepared statement is '31,464'. at org.apache.derby.client.am.PreparedStatement.checkForValidParameterIn dex(PreparedStatement.java(Compiled Code)) at org.apache.derby.client.am.PreparedStatement.checkSetterPreconditions (PreparedStatement.java(Inlined Compiled Code)) at org.apache.derby.client.am.PreparedStatement.setIntX(PreparedStatemen t.java(Inlined Compiled Code)) ... 5 more 27a35,37 java.sql.SQLException : Statement too complex. Try rewriting the query to remove complexity. Eliminating many duplicate expressions or breaking up the query and storing interim results in a temporary table can often help resolve this error . SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:fillResultSe t code_length (69127 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203axd010x50a9065e11. Caused by: org.apache.derby.client.am.SqlException: Statement too complex. Try rewriting the query to remove complexity. Eliminating many duplicate expression s or breaking up the query and storing interim results in a temporary table can often help resolve this error. SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:fillResultSet code_length (69127 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203axd010x50a9065e11 . ... 3 more 28 add java.sql.SQLException: Java exception: ': java.lang.OutOfMemoryError'. Caused by: org.apache.derby.client.am.SqlException: Java exception: ': java.lang.OutOfMemoryError '. ... 3 more Test Failed. -- 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-1315) largeCodeGen fails with framework DerbyNetClient
[ http://issues.apache.org/jira/browse/DERBY-1315?page=all ] Ramandeep Kaur updated DERBY-1315: -- Attachment: largeCodeGen.out largeCodeGen.tmpmstr largeCodeGen.tmp largeCodeGen fails with framework DerbyNetClient Key: DERBY-1315 URL: http://issues.apache.org/jira/browse/DERBY-1315 Project: Derby Type: Bug Components: Test Versions: 10.2.0.0 Environment: Linux - Suse 2.6.5-7.252 Reporter: Ramandeep Kaur Priority: Blocker Attachments: largeCodeGen.out, largeCodeGen.tmp, largeCodeGen.tmpmstr The test case lang/largeCodeGen.java was run as is without giving any -Djvmflags=-mx512M -ms512M and gave the following error: *** Start: largeCodeGen jdk1.4.2 largeDataTests:largeDataTests 2006-04-29 08:30:04 *** 27a28 JVMST109: Insufficient space in Javaheap to satisfy allocation request Test Failed. *** End: largeCodeGen jdk1.4.2 largeDataTests:largeDataTests 2006-04-29 08:32:01 *** Then the test case lang/largeCodeGen.java was run with -Djvmflags=-mx512M -ms512M, and it gave the following error: PASS: IN clause with 97000 parameters 20 del PASS: PREPARE: IN clause with 98000 parameters 21 del PASS: IN clause with 98000 parameters 22 del FAILED QUERY: IN clause with 99000 parameters. 22a19 FAILED QUERY: IN clause with 97000 parameters. Test Failed. Then I modified test case lang/largeCodeGen.java to set PRINT_FAILURE_EXCEPTION to true and ran the test again. This time I got the following error and stack trace: MasterFileName = master/largeCodeGen.out 15a16,18 java.sql.SQLException: Statement too complex. Try rewriting the query to remove complexity. Eliminating many duplicate expressions or breaking up the query and storing interim results in a temporary table can often help resolve this error . SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:e1 code_leng th (65577 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203ax d010x50a9065e9. Caused by: org.apache.derby.client.am.SqlException: Statement too complex. Try rewriting the query to remove complexity. Eliminating many duplicate expression s or breaking up the query and storing interim results in a temporary table can often help resolve this error. SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:e1 code_length (65577 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203axd010x50a9065e9 . ... 4 more 19 del PASS: IN clause with 97000 parameters 20 del PASS: PREPARE: IN clause with 98000 parameters 21 del PASS: IN clause with 98000 parameters 22 del FAILED QUERY: IN clause with 99000 parameters. 22a22,29 FAILED QUERY: IN clause with 97000 parameters. java.sql.SQLException: The parameter position '31,465' is out of range. The number of parameters for this prepared statement is '31,464'. at org.apache.derby.client.am.PreparedStatement.setInt(PreparedStatement .java(Compiled Code)) Caused by: org.apache.derby.client.am.SqlException: The parameter position '31 ,465' is out of range. The number of parameters for this prepared statement is '31,464'. at org.apache.derby.client.am.PreparedStatement.checkForValidParameterIn dex(PreparedStatement.java(Compiled Code)) at org.apache.derby.client.am.PreparedStatement.checkSetterPreconditions (PreparedStatement.java(Inlined Compiled Code)) at org.apache.derby.client.am.PreparedStatement.setIntX(PreparedStatemen t.java(Inlined Compiled Code)) ... 5 more 27a35,37 java.sql.SQLException : Statement too complex. Try rewriting the query to remove complexity. Eliminating many duplicate expressions or breaking up the query and storing interim results in a temporary table can often help resolve this error . SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:fillResultSe t code_length (69127 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203axd010x50a9065e11. Caused by: org.apache.derby.client.am.SqlException: Statement too complex. Try rewriting the query to remove complexity. Eliminating many duplicate expression s or breaking up the query and storing interim results in a temporary table can often help resolve this error. SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:fillResultSet code_length (69127 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203axd010x50a9065e11 . ... 3 more 28 add java.sql.SQLException: Java exception: ': java.lang.OutOfMemoryError'. Caused by: org.apache.derby.client.am.SqlException: Java exception: ': java.lang.OutOfMemoryError '. ... 3 more Test Failed. -- This message is automatically generated by JIRA. - If you think it was sent
[jira] Commented: (DERBY-1286) Fill in Clob methods required for JDBC3 compliance
[ http://issues.apache.org/jira/browse/DERBY-1286?page=comments#action_12378987 ] Daniel John Debrunner commented on DERBY-1286: -- Is there a good definition in the specification as to how the Clob.setXXX methods are defined to work? Section 16.3.3. of JDBC 3.0 has wording that is pretty vague. The javadoc for these methods doesn't help much either. (Similar concern for Blob.setXXX) Q1 - I can think of three possible implementations for the setXXX methods: A) Overwite any existing data from the passed in position B) Replace the data from passed in position onwards C) Insert the data into the value at the position For example, with an existing Clob with value To be or not to be, and calling setString(7, is all) I can see getting: A) To be is all to be B) To be is all C) To be is allor not to be From a quick check of the (ugly, see DERBY-684) client code, I think it implements B. Q2 - is that if I call setXXXStream() but never write to the stream, is the value modified? What if the stream is written to with 0 bytes/characters? If the defined behaviour above is B) then there's a case to be made that it should be truncated to length matching the passed in position. Q3 - setString returns the number of characters written, is that allowed to be different to the number of characters that are requested to be written? Like OutputStream.writr(byte[])? Sorry if these answers are obvious. BTW - there is a bug in the javadoc for Clob.truncate() that indicates for the parameter that the truncation is in bytes. The overview of the method indicates correctly it is in characters. This still seems to be an issue in JDBC 4. Fill in Clob methods required for JDBC3 compliance -- Key: DERBY-1286 URL: http://issues.apache.org/jira/browse/DERBY-1286 Project: Derby Type: Improvement Components: JDBC Versions: 10.2.0.0 Reporter: Rick Hillegas Fix For: 10.2.0.0 Fill in Clob methods which we need to be JDBC3-compliant: - The following java.sql.CallableStatement methods: * getClob(int) - The following java.sql.ResultSet methods: * updateClob(int,java.sql.Clob) * updateClob(java.lang.String,java.sql.Clob) - The following java.sql.Clob methods: * setString(long,java.lang.String) * setString(long,java.lang.String,int,int) * setAsciiStream(long) * getCharacterStream(long,long) * setCharacterStream(long) * truncate(long) -- 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-1285) Finish JDBC3 Blob implementation
[ http://issues.apache.org/jira/browse/DERBY-1285?page=comments#action_12378989 ] Daniel John Debrunner commented on DERBY-1285: -- See questions in DERBY-1286 about the Clob.setXXX() methods. I have similar questions over the Blob.setXXX methods for the defined behaviour. Finish JDBC3 Blob implementation Key: DERBY-1285 URL: http://issues.apache.org/jira/browse/DERBY-1285 Project: Derby Type: Improvement Components: JDBC Versions: 10.2.0.0 Reporter: Rick Hillegas Fix For: 10.2.0.0 Fill in the following methods required for JDBC3 compliance: - The following java.sql.CallableStatement methods: * getBlob(int) - The following java.sql.ResultSet methods: * updateBlob(int,java.sql.Blob) * updateBlob(java.lang.String,java.sql.Blob) - The following java.sql.Blob methods: * java.sql.Blob.setBytes(long,byte[]) * setBytes(long,byte[],int,int) * getBinaryStream(long,long) * setBinaryStream(long) * truncate(long) -- 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-1091) Test harness does not pass jvm flags properly if there are more than 1 property in jvm flags
[ http://issues.apache.org/jira/browse/DERBY-1091?page=comments#action_12378990 ] Ramandeep Kaur commented on DERBY-1091: --- Another problem with parsing of -Djvmflags is found while running test suite largeData. While running this suite, I need to pass -Djvmflags=-mx512M -ms512M so that the values -mx512M -ms512M are passed while running individual test cases and while starting network server in case of framework=DerbNetClient. However, RunSuite class does not seem to parse -Djvmflags well and does not further pass it properply whereas RunTest class parses the flags properly. Test harness does not pass jvm flags properly if there are more than 1 property in jvm flags Key: DERBY-1091 URL: http://issues.apache.org/jira/browse/DERBY-1091 Project: Derby Type: Test Components: Test Versions: 10.2.0.0 Environment: Windows 2000 Reporter: Ramandeep Kaur Priority: Minor To run Derby tests with EMMA for Code coverage, there is a need to set up emma flag -Djvmflags=-Demma.verbosity.level=silent. This is basically to enable EMMA not to print out any messages to avoid having any diffs. This all works fine when running Derby tests with EMMA for jdk142, jdk15, jdk131 etc because there is no other jvm flag that is passed while calling RunSuite Command. Now, while running tests with j2me/cdc/foundation, another value needs to be passed as jvmflag which is -Djvmflags=Dij.dataSource=org.apache.derby.jdbc.EmbeddedSimpleDataSource. I tried to combine values for both jvm flags as following, but it did not work properly: 1. -Djvmflags='-Demma.verbosity.level=silent -Dij.dataSource=org.apache.derby.jdbc.EmbeddedSimpleDataSource' During this run, the value that was further passed while running one test was Djvmflags='-Demma.verbosity.level=silent. As you can notice it took jvm flag as '-Demma.verbosity.level=silent 2. -Djvmflags=-Demma.verbosity.level=silent -Dij.dataSource=org.apache.derby.jdbc.EmbeddedSimpleDataSource During this run, the value that was further passed while running one test was Djvmflags=-Demma.verbosity.level=silent. As you can notice it took jvm flag as -Demma.verbosity.level=silent From the above it looks like test harness needs to be changed so that it can parse multiple values for jvm flags properly. -- 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-1154) derbynet/testSecMec.java fails with Sun JDK 1.3
[ http://issues.apache.org/jira/browse/DERBY-1154?page=all ] Sunitha Kambhampati updated DERBY-1154: --- Attachment: masterupdates_testSecMec.diff.txt I am attaching a patch to fix this master update issue for the 1.3.1 vms as well as for the ibm142 jvm ( that was caused by error messages change). Can someone please commit this patch. Ran this test with jdk131,ibm131,ibm142. Thanks. derbynet/testSecMec.java fails with Sun JDK 1.3 --- Key: DERBY-1154 URL: http://issues.apache.org/jira/browse/DERBY-1154 Project: Derby Type: Bug Components: Regression Test Failure Versions: 10.2.0.0 Reporter: A B Priority: Minor Attachments: masterupdates_testSecMec.diff.txt derbynet/testSecMec.java fails with Sun JDK 1.3: SECMEC_EUSRIDPWD:EXCEPTION testSecurityMechanism() Security exception encountered, see next exception for details. SECMEC_EUSRIDPWD:EXCEPTION testSecurityMechanism() Security exception encountered, see next exception for details. Caused by exception class java.security.NoSuchProviderException: null ... (and so forth) Does not fail with 1.4, so probably just a master update. -- 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: LargeCodegen test fails with derbyclient while running largeData test suite
Hi All, It looks like we have 2 different issues now with lang/largeCodeGen.java test cases. 1. jvm heap size need to be increased while running test case lang/largeCodeGen.java which is easy to do in case of framework embedded as the change can be made to largeCodeGen_app.properties file. In case of DerbyNetClient, java heap size need to be increased while starting Network Server as well which can be done by giving -Djvmflags=-mx512M -ms512M while running lang/largeCodeGen.java test case individually with RunTest class. However whilerunning lang/largeCodeGen.java as part of suite largeData with RunSuite class, -Djvmflags=-mx512M -ms512M can not be given as command line as RunSuite does not parse this flag properly and does not pass it to RunTest properly. Now, if we change NetworkServer.java class toincrease jvm heap size, it will be increased for all the test cases. I already have a JIRA bug open (http://issues.apache.org/jira/browse/DERBY-1091 )to fix jvmflags parsing problem. 2 Now when the jvm heap size is increased for both test case lang/largeCodeGen.java and Network Server, we do not get any heap size related problem. However, we get another error as explained in my posts above. I have opened JIRA bug ( http://issues.apache.org/jira/browse/DERBY-1315) for that as well. Thanks, Raman On 5/4/06, Ramandeep Kaur [EMAIL PROTECTED] wrote: Hi, I reran testcase largeCodeGen with both frameworks - embedded and DerbyNetClient. Embedded For embedded, test passed in the following cases: 1. when test was run by passig-Djvmflags=-Xmx1024M -Xms1024M from command lineas follows: java -Dverbose=true -Djvmflags=-Xmx1024M -Xms1024M org.apache.derbyTesting.functionTests.harness.RunTest lang/largeCodeGen.java 2. When java/testing/org/apache/derbyTesting/functionTests/tests/lang/largeCodeGen_app.properties was modified and the line jvmflags=-Xmx512M -Xms512M was replaced with jvmflags=-Xmx1024M -Xms1024M DerbyNetClient --With framework DerbyNetClient, there is still same error as given in my message above. Note: Please note that there is difference in jvmflags while running with embedded and DerbyNetClient frameworks. With embedded frameworks -Xmx and -Xms are given for jvmflags With DerbyNetClient frameworks -mx and -ms are are given for jvmflags. Thanks, Ramandeep Kaur On 5/3/06, Manjula G Kutty [EMAIL PROTECTED] wrote: Ramandeep Kaur wrote: Hi, I ran largeCodeGen as following:java -Dverbose=true -Djvmflags=-mx512M -ms512M -Dframework=DerbyNetClient org.apache.derbyTesting.functionTests.harness.RunTest lang/largeCodeGen.java With the above, I did NOT get usual error which was *** Start: largeCodeGen jdk1.4.2 largeDataTests:largeDataTests 2006-04-29 08:30:04 *** 27a28 JVMST109: Insufficient space in Javaheap to satisfy allocation request Test Failed. *** End: largeCodeGen jdk1.4.2 largeDataTests:largeDataTests 2006-04-29 08:32:01 *** Instead, I got another error which is PASS: IN clause with 97000 parameters 20 del PASS: PREPARE: IN clause with 98000 parameters 21 del PASS: IN clause with 98000 parameters 22 del FAILED QUERY: IN clause with 99000 parameters. 22a19 FAILED QUERY: IN clause with 97000 parameters. Test Failed. Here are the contents of test.txt *** Start: largeCodeGen jdk1.4.2 DerbyNetClient 2006-05-02 17:06:24 *** Initialize for framework: DerbyNetClient java -mx512M -ms512M - Dderby.system.home=/local0/NightlyBuildResults.2006-05-02/ ibm142_largeDataTests/DerbyNetClient/largeCodeGen - Djava.security.manager -Djava .security.policy=/local0/NightlyBuildResults.2006-05-02/ibm142_largeDataTests/de rby_tests.policy -DderbyTesting.codejar=file:/local1/cloudtst/dev/src/jars/insan e/ -DderbyTesting.codedir=/local1/cloudtst/dev/src/jars/insane -DderbyTesting.se rverhost=localhost - DderbyTesting.clienthost=localhost -DderbyTesting.codeclasse s=file://unused/ org.apache.derby.drda.NetworkServerControl start Attempt to shutdown framework: DerbyNetClient 19 del PASS: IN clause with 97000 parameters 20 del PASS: PREPARE: IN clause with 98000 parameters 21 del PASS: IN clause with 98000 parameters 22 del FAILED QUERY: IN clause with 99000 parameters. 22a19 FAILED QUERY: IN clause with 97000 parameters. Test Failed. *** End: largeCodeGen jdk1.4.2 DerbyNetClient 2006-05-02 17:08:07 *** Now it looks like it could be a diff problem. Any idea??? Thanks, Raman On 2/27/06, *John Embretsen* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Kathey Marsden wrote: Manjula G Kutty wrote: I have closed all the statements, prepared statements and resultsets in the largeCodeGen.java file. But still the test passes with embedded but fails with derbyClient. I'm attaching the modified largeCodeGen.java file Hi Manjula, Because this test throws a lot of exceptions, the statements and prepared statements would need to be closed in a finally block. But I just noticed something that might be causing this and it is related to
[jira] Updated: (DERBY-900) Remove use of String(byte[]) and String(byte[], int, int) constructors in network client leading to non-portable behaviour
[ http://issues.apache.org/jira/browse/DERBY-900?page=all ] Kathey Marsden updated DERBY-900: - Attachment: testsecmec.zip I applied the patch derby900_p2_cleanup.diff.txt I had to merge some files after applying and then ran derbynetclientmats. The test derbynet/testSecMec failed with client and on rerun. I ran with java version 1.4.2_07 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_07-b05) Java HotSpot(TM) Client VM (build 1.4.2_07-b05, mixed mode) The tail end of the test seems to be cut off. Attached is the test output. Remove use of String(byte[]) and String(byte[], int, int) constructors in network client leading to non-portable behaviour -- Key: DERBY-900 URL: http://issues.apache.org/jira/browse/DERBY-900 Project: Derby Type: Bug Components: Network Client Reporter: Daniel John Debrunner Assignee: Sunitha Kambhampati Fix For: 10.2.0.0 Attachments: Derby900.p2.diff.txt, TestEnc.java, derby900.diff.p1.txt, derby900.p2.stat.txt, derby900.p2_encodingChange.diff.txt, derby900.stat.p1.txt, derby900.test.diff.txt, derby900.test.stat.txt, derby900_p2_cleanup.diff.txt, derby900_p2_cleanup.stat.txt, for_10.1_derby900.diff.p1.txt, for_10.1_derby900.stat.p1.txt, testsecmec.zip These constructors use the Java default platform encoding to convert the bytes to a String, this typically leads to bugs on platforms with different encodings. Replace with code using fixed conversion, or alternative mechanisms. If the call is required its use should be commented as to why it is required. org.apache.derby.client.am.ClobOutputStream - some existing bug? org.apache.derby.client.am.DateTime - see DERBY-877 org.apache.derby.client.am.sqlca I generated this list using the Java search in eclipse for references to the constructors String(byte[]) String(byte[],int,int) -- 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] Reopened: (DERBY-683) Use correct encoding for ClobOutputStream on client
[ http://issues.apache.org/jira/browse/DERBY-683?page=all ] Deepa Remesh reopened DERBY-683: Reopening to port this fix to 10.1 branch Use correct encoding for ClobOutputStream on client --- Key: DERBY-683 URL: http://issues.apache.org/jira/browse/DERBY-683 Project: Derby Type: Bug Components: Network Client Versions: 10.1.1.1, 10.1.1.0 Environment: all Reporter: Sunitha Kambhampati Assignee: Deepa Remesh Fix For: 10.2.0.0 Attachments: DERBY-683_tstpatch3_2006_02_16.diff, DERBY-683_tstpatch3_2006_02_16.stat, ascii.txt, clob.java, derby-683.diff, derby-683_021006.diff, derby-683_021006.stat, derby-683_tests.diff, derby-683_tests.status In client, there is code in ClobOutputStream which uses this api - new String(byte[]). Per the java api http://java.sun.com/j2se/1.4.2/docs/api/java/lang/String.html#String(byte[]) ,this will construct a string by decoding the array of bytes using the platform's default character set. org.apache.derby.client.am.ClobOutputStream is used for Clob.setAsciiStream and the write methods use the String(byte[]) which is incorrect because it will use the default platform encoding. Per the jdbcapi , this should use ascii encoding. In areas related to Clobs, also check for other places where String(byte[]) is used,as it may not be the desired behavior. Dan pointed this problem here : http://issues.apache.org/jira/browse/DERBY-463?page=comments#action_12356742 -- 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
jdk16 and suite derbyall - 128 failures
Hi, I ran suite derbyall with sun jdk16 and got 128 failures. I checked http://www.multinet.no/~solberg/public/Apache/DerbyJDK16/testlog/JDK16Jvm1.6SunOS-5.10_i86pc-i386/405484 derbyall_diff.txt and found that Sun Database Technology Group (DBTG) Regression Test Resultsare alsoshowing same errors. Wanted to know if there is any action plan to fix these failures. If not, should I open JIRA bug for it. Details are as following: Environment: -- OS: Windows XP JVM: sun jdk16 java version 1.6.0-beta2 Java(TM) SE Runtime Environment (build 1.6.0-beta2-b81) Java HotSpot(TM) Client VM (build 1.6.0-beta2-b81, mixed mode) Errors - derbyall/derbynetclientmats/derbynetmats.fail:derbynet/DerbyNetAutoStart.java derbyall/derbynetmats/derbynetmats.fail:derbynet/DerbyNetAutoStart.java /derbyall.fail:nist/schema1.sql /derbyall.fail:nist/basetab.sql /derbyall.fail:nist/schema5.sql /derbyall.fail:nist/schema8.sql /derbyall.fail:nist/temp_schem10.sql /derbyall.fail:nist/temp_cts5sch2.sql /derbyall.fail:nist/temp_cts5tab.sql /derbyall.fail:nist/flattab.sql /derbyall.fail:nist/dml012.sql /derbyall.fail:nist/dml013.sql /derbyall.fail:nist/dml018.sql /derbyall.fail:nist/dml022.sql /derbyall.fail:nist/dml025.sql /derbyall.fail:nist/dml044.sql /derbyall.fail:nist/dml045.sql /derbyall.fail:nist/dml051.sql /derbyall.fail:nist/dml059.sql /derbyall.fail:nist/dml061.sql /derbyall.fail:nist/dml073.sql /derbyall.fail:nist/dml087.sql /derbyall.fail:nist/dml090.sql /derbyall.fail:nist/dml106.sql /derbyall.fail:nist/dml108.sql /derbyall.fail:nist/dml114.sql /derbyall.fail:nist/dml141.sql /derbyall.fail:nist/dml144.sql /derbyall.fail:nist/dml162.sql /derbyall.fail:nist/dml177.sql /derbyall.fail:nist/dml010.sql /derbyall.fail:nist/dml015.sql /derbyall.fail:nist/dml020.sql /derbyall.fail:nist/dml037.sql /derbyall.fail:nist/dml038.sql /derbyall.fail:nist/dml042.sql /derbyall.fail:nist/dml043.sql /derbyall.fail:nist/dml047.sql /derbyall.fail:nist/dml056.sql /derbyall.fail:nist/dml065.sql /derbyall.fail:nist/dml076.sql /derbyall.fail:nist/sdl012.sql /derbyall.fail:nist/dml029.sql /derbyall.fail:nist/yts796.sql /derbyall.fail:nist/dml075.sql /derbyall.fail:nist/dml024.sql /derbyall.fail:nist/dml070.sql /derbyall.fail:nist/dml147.sql /derbyall.fail:nist/dml009.sql /derbyall.fail:nist/dml008.sql /derbyall.fail:nist/dml014.sql /derbyall.fail:nist/dml016.sql /derbyall.fail:nist/dml021.sql /derbyall.fail:nist/dml034.sql /derbyall.fail:nist/dml023.sql /derbyall.fail:nist/dml026.sql /derbyall.fail:nist/dml033.sql /derbyall.fail:nist/dml039.sql /derbyall.fail:nist/dml050.sql /derbyall.fail:nist/dml052.sql /derbyall.fail:nist/dml053.sql /derbyall.fail:nist/dml055.sql /derbyall.fail:nist/dml057.sql /derbyall.fail:nist/dml058.sql /derbyall.fail:nist/dml155.sql /derbyall.fail:nist/xts729.sql /derbyall.fail:nist/xts730.sql /derbyall.fail:nist/yts797.sql /derbyall.fail:nist/yts798.sql /derbyall.fail:nist/dml069.sql /derbyall.fail:nist/dml080.sql /derbyall.fail:nist/dml081.sql /derbyall.fail:nist/dml083.sql /derbyall.fail:nist/dml085.sql /derbyall.fail:nist/dml132.sql /derbyall.fail:nist/dml099.sql /derbyall.fail:nist/dml049.sql /derbyall.fail:nist/dml173.sql /derbyall.fail:nist/dml174.sql /derbyall.fail:nist/dml179.sql /derbyall.fail:nist/yts812.sql /derbyall.fail:nist/dml001.sql /derbyall.fail:nist/dml004.sql /derbyall.fail:nist/dml035.sql /derbyall.fail:nist/dml046.sql /derbyall.fail:nist/dml060.sql /derbyall.fail:nist/dml068.sql /derbyall.fail:nist/yts799.sql /derbyall.fail:nist/dml001.sql /derbyall.fail:nist/dml079.sql /derbyall.fail:nist/dml165.sql /derbyall.fail:nist/dml104.sql /derbyall.fail:nist/dml112.sql /derbyall.fail:nist/dml148.sql /derbyall.fail:nist/dml019.sql /derbyall.fail:nist/dml149.sql /derbyall.fail:nist/dml168.sql /derbyall.fail:nist/dml170.sql /derbyall.fail:nist/xts752.sql /derbyall.fail:nist/xts753.sql /derbyall.fail:nist/cdr002.sql /derbyall.fail:nist/cdr003.sql /derbyall.fail:nist/cdr004.sql /derbyall.fail:nist/cdr005.sql /derbyall.fail:nist/cdr006.sql /derbyall.fail:nist/cdr007.sql /derbyall.fail:nist/cdr027.sql /derbyall.fail:nist/cdr030.sql /derbyall.fail:nist/dml134.sql /derbyall.fail:nist/dml005.sql /derbyall.fail:nist/dml011.sql /derbyall.fail:nist/dml027.sql /derbyall.fail:nist/dml082.sql /derbyall.fail:nist/dml091.sql /derbyall.fail:nist/dml119.sql /derbyall.fail:nist/dml130.sql /derbyall.fail:nist/dml158.sql /derbyall.fail:nist/dml178.sql /derbyall.fail:nist/dml181.sql /derbyall.fail:nist/dml182.sql /derbyall.fail:nist/xts701.sql /derbyall.fail:nist/xts731.sql /derbyall.fail:nist/xts740.sql /derbyall.fail:nist/xts742.sql /derbyall.fail:nist/xts760.sql /derbyall.fail:nist/yts811.sql /derbyall.fail:nist/dml160.sql /derbyall.fail:nist/schema4.sql-- Ramandeep Kaur [EMAIL PROTECTED]
[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_12378998 ] Daniel John Debrunner commented on DERBY-1029: -- With the 10.2 release being delayed what's the current plan for this, fix BOOLEAN to match the spec or continue with removing it from the branch? Seems like with the more time available, Rick, you could continue your original itch to implement BOOLEAN? 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 Type: Sub-task Components: SQL Versions: 10.2.0.0 Reporter: Kathey Marsden Assignee: Rick Hillegas Priority: Blocker Fix For: 10.2.0.0 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
Re: Feedback integrate/plugin_howto.html
Joe Dorocak wrote: Dear Derby-Dev, Regarding your article Using the 10.1 Core and 1.1 UI Derby plug-ins at URL http://db.apache.org/derby/integrate/plugin_howto.html#Installing+the+plug-i ns I have tried to install the Derby plugins twice now, without success. I checked the md5 sums for both derby_core_plugin_10.1.2.zip and derby_ui_plugin_1.1.0.zip. They were both OK. I unzipped them both into C:\eclipse, my ECLIPSE_HOME, as a result there are 3 new subdirectories under C:\eclipse\plugins: org.apache.derby.core_10.1.2 org.apache.derby.plugin.doc_1.1.0 org.apache.derby.ui_1.1.0 However, after restarting eclipse, Version: 3.1.2, Build id: M20060118-1600, Apache Derby does NOT show up in the menu when I right-click on my project. Additionally, under HelpAbout Eclipse SDKPlug-in Details, when I sort on Plug-in Id, org.apache.axis is followed by org.apache.lucene and NOT by org.apache.derby.core and the 2 other derby items, as I expected. I hope you can help me. If you want, I can provide a listing of the directory contents of the derby plugins, as well as a listing of the relevant plugin.xmls. Thanks in advance. Regards, Joe Dorocak [EMAIL PROTECTED] Hi Joe - You may have already seen this but your issue is very close to the problem posted by JavaJosh earlier with the same subject line. The archive of the begining report is at: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200605.mbox/[EMAIL PROTECTED] There were responses which I do not see in the archives yet so am pasting here in case it is of help: [EMAIL PROTECTED] wrote: Hi, From the output you've shown below it appears that you have the 3 plugins installed, however I'm not sure why you are having the problem. The version of Eclipse I have is 3.1.0. When I look at the configuration details of my installation it shows all three plugins in the registry as well as in the configured plugins section. I noticed it does not show the UI or Doc plugins in the registry section for you. Later today I'll install 3.1.2 and see if I run into the same problems you are. As a quick suggestion that might help, try restarting eclipse with the -clean option. eclipse.exe -clean Thanks, Susan Rajesh Kartha wrote: Can you also look in the workspace log file if there are any errors/exceptions. In your case the file should be: C:\bin\eclipse\workspace\.metadata\.log Any reason for not loading/starting the plug-ins will typically be written to this .log file. -Rajesh
Re: LargeCodegen test fails with derbyclient while running largeData test suite
On 5/10/06, Ramandeep Kaur [EMAIL PROTECTED] wrote: Hi All, [snip] 1. jvm heap size need to be increased while running test case lang/largeCodeGen.java which is easy to do in case of framework embedded as the change can be made to largeCodeGen_app.properties file. In case of DerbyNetClient, java heap size need to be increased while starting Network Server as well which can be done by giving -Djvmflags=-mx512M -ms512M while running lang/largeCodeGen.java test case individually with RunTest class. However whilerunning lang/largeCodeGen.java as part of suite largeData with RunSuite class, -Djvmflags=-mx512M -ms512M can not be given as command line as RunSuite does not parse this flag properly and does not pass it to RunTest properly. Now, if we change NetworkServer.java class toincrease jvm heap size, it will be increased for all the test cases. I already have a JIRA bug open ( http://issues.apache.org/jira/browse/DERBY-1091 )to fix jvmflags parsing problem. I may be misunderstanding the problem, so this is to confirm - do you want to run all tests in the suite largeDataTests with these jvmflags? As a workaround, does it work to have these jvmflags in every tests' _app.properties file? Myrna
[jira] Created: (DERBY-1316) Wrong value returned by DatabaseMetaData.locatorsUpdateCopy()
Wrong value returned by DatabaseMetaData.locatorsUpdateCopy() - Key: DERBY-1316 URL: http://issues.apache.org/jira/browse/DERBY-1316 Project: Derby Type: Bug Components: JDBC Versions: 10.2.0.0 Reporter: Rick Hillegas Fix For: 10.2.0.0 Both the embedded and network implementations of DatabaseMetaData return the wrong value for this method, which was added in JDBC4. This method currently returns false but should return true. Returning false means that your Blob/Clobs are backed by SQL Locators and therefore that set() methods on your Lobs write-through to 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
Re: jdk16 and suite derbyall - 128 failures
Hi Ramandeep, This issue is covered by the umbrella DERBY-955 jira. The problem has been analyzed this far: The tests run cleanly against the classtree but fail because of permissions exceptions when run against jar files. We suspect an asymmetry in the permissions granted to the classtree and the jar files by derby_tests.policy. Please feel free to scratch this itch! Regards, -Rick Ramandeep Kaur wrote: Hi, I ran suite derbyall with sun jdk16 and got 128 failures. I checked http://www.multinet.no/~solberg/public/Apache/DerbyJDK16/testlog/JDK16Jvm1.6SunOS-5.10_i86pc-i386/405484 derbyall_diff.txt http://www.multinet.no/%7Esolberg/public/Apache/DerbyJDK16/testlog/JDK16Jvm1.6SunOS-5.10_i86pc-i386/405484%20derbyall_diff.txt and found that Sun Database Technology Group (DBTG) Regression Test Results http://www.multinet.no/%7Esolberg/public/Apache/index.html are also showing same errors. Wanted to know if there is any action plan to fix these failures. If not, should I open JIRA bug for it.
SVN server problems (fwd)
Original Message Subject: SVN server problems (fwd) Date: Wed, 10 May 2006 21:21:45 -0400 (EDT) From: Henri Yandell [EMAIL PROTECTED] Reply-To: community@apache.org To: community@apache.org Spreading the word a bit. -- Forwarded message -- From: Henri Yandell [EMAIL PROTECTED] Date: May 10, 2006 6:15 PM Subject: SVN server problems To: Apache Infrastructure [EMAIL PROTECTED] Putting an email on the infra list to provide an update (from a spectator's point of view) on today's issues. Minotaur, which is chiefly handling the SVN repository, Apache project sites, people.apache.org sites and [EMAIL PROTECTED] email addresses had a kernel panic and was acting up after the reboot (errors on commands that should not have errored). Things were taken down for a memtest run and the static websites (not the dynamic tcl.apache or perl.apache) were failed over to Ajax (failover machine in Europe). The memtest passed, and the subversion repositories are being checked for validity while also making sure that an up to date backup of the svn repositories is made. Minotaur is slowly being brought back online. Sometime tonight read-only SVN will be re-enabled; and presuming things go well I imagine read-write and unix accounts will be turned back on. Medium term, SVN will be moved to one of the machines that Infra have recently been getting ready. As an aside. It's very impressive to sit on #asfinfra and watch the infra@ volunteers dealing with such things. Half a dozen people have juggled their schedules to spend a lot of today dealing with the problem, and I'm sure they'll be putting many more hours in to get there. So remember to say thanks in Dublin next month if you get the chance :) Hen
