[jira] Commented: (DERBY-1962) Convert jdbcapi/resultsetJdbc30.java to junit
[
http://issues.apache.org/jira/browse/DERBY-1962?page=comments#action_12442815 ]
Knut Anders Hatlen commented on DERBY-1962:
---
I think the patch looks good, but it seems the preferred way to make an
embedded-only suite has changed to
public static Test suite() {
return TestConfiguration.embeddedSuite(ResultSetJDBC30Test.class);
}
Minor nits (not important to fix, only suggestions on how to reduce the amount
of code in case you plan to convert more tests to JUnit):
- I think fail(...) is clearer than assertTrue(..., false)
- it is not necessary to retrieve the connection object so often since
BaseJDBCTestCase has helper methods like createStatement(), prepareStatement()
and commit().
Convert jdbcapi/resultsetJdbc30.java to junit
-
Key: DERBY-1962
URL: http://issues.apache.org/jira/browse/DERBY-1962
Project: Derby
Issue Type: Sub-task
Components: Test
Reporter: Fernanda Pizzorno
Assigned To: Fernanda Pizzorno
Attachments: derby-1962.diff, derby-1962.stat
--
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: Incorrect code in NetworkDerbyControlImpl.shutdown()??
Daniel John Debrunner [EMAIL PROTECTED] writes:
In NetworkDerbyControlImpl.shutdown() there is code that logs the
message DRDA_ShutdownError.S, which is:
Unable to shutdown server on port {0} on host {1}.
The position of the code looks wrong, it is in a catch block for an
exception with an if statement to check that the server has looped
through SHUTDOWN_CHECK_ATTEMPTS.
It seems that really the intention of the code would mean it should be
logged outside the loop. See the following extracted code, it seems to
me the code between the MOVE and END-MOVE comments should be moved to
the end, where the TO-HERE comment is?
I agree. (ntry == SHUTDOWN_CHECK_ATTEMPTS) is always false inside the
loop, so the message is never printed. Moving the code as you
suggested sounds fine. Then the message will be printed if and only if
ping() has returned successfully SHUTDOWN_CHECK_ATTEMPTS times, which
seems to be the intention.
Dan.
int ntry;
for (ntry = 0; ntry SHUTDOWN_CHECK_ATTEMPTS; ntry++)
{
Thread.sleep(SHUTDOWN_CHECK_INTERVAL);
try {
ping();
} catch (Exception e)
{
// as soon as we can't ping return
// MOVE
if (ntry == SHUTDOWN_CHECK_ATTEMPTS)
consolePropertyMessage(DRDA_ShutdownError.S, new String [] {
Integer.toString(portNumber), hostArg});
// END-MOVE
break;
}
}
// TO-HERE
--
Knut Anders
[testing]RunTest junitTests/derbyNet/CompatibilityTest.java hangs on windows XP.
Hi, all: I have ran the derbyall tests on windows, but it hangs on RunTest junitTests/derbyNet/CompatibilityTest.java. But it passes on Unbuntu. Any suggestion? Thanks.-- Leo LiChina Software Development Lab, IBM
[jira] Created: (DERBY-1967) UNION (ALL) contraint violation problem
UNION (ALL) contraint violation problem
---
Key: DERBY-1967
URL: http://issues.apache.org/jira/browse/DERBY-1967
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.2.1.6, 10.1.3.1
Environment: derby v10.1.3.1 and v10.2.1.6 on linux (FC5), jdk
1.5.0_06-b05
and jdk 1.6.0-rc-b99.
Reporter: Radu Radutiu
The following simple test case gives an error:
create table a (f1 varchar(10));
create table b (f2 varchar(10));
insert into b values('test');
select nullif('x','x') as f0, f1 from a
union all
select nullif('x','x') as f0, nullif('x','x') as f1 from b;
ERROR 23502: Column 'F0' cannot accept a NULL value.
SQLState(23502) vendor code(3)
However the following works ok:
drop table a;
drop table b;
create table a (f1 int);
create table b (f2 int);
insert into b values(1);
select nullif('x','x') as f0, f1 from a
union all
select nullif('x','x') as f0, nullif(1,1) as f1 from b;
The test case is a simplification of a query generated by Hibernate
with the table per class inheritance strategy. Both queries work ok on
MSSQL and PostgreSQL. On Derby only the second query works, the first
one giving a contraint violation.
--
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-1968) Derby tools guide: Long line in documentation of ij.dataSource
Derby tools guide: Long line in documentation of ij.dataSource -- Key: DERBY-1968 URL: http://issues.apache.org/jira/browse/DERBY-1968 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.1.6, 10.3.0.0 Environment: PDF files Reporter: Øystein Grøvlen Priority: Trivial In the definition of ij.dataSource in the Tools Guide, a line is wider than the page. (Page 16 in 10.2 documentation) -- 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-1968) Derby tools guide: Long line in documentation of ij.dataSource
[ http://issues.apache.org/jira/browse/DERBY-1968?page=comments#action_12442885 ] Øystein Grøvlen commented on DERBY-1968: I think it would also be good if the associated example (and other examples in this manual) included a statement of what it is trying to achieve. Derby tools guide: Long line in documentation of ij.dataSource -- Key: DERBY-1968 URL: http://issues.apache.org/jira/browse/DERBY-1968 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.1.6, 10.3.0.0 Environment: PDF files Reporter: Øystein Grøvlen Priority: Trivial In the definition of ij.dataSource in the Tools Guide, a line is wider than the page. (Page 16 in 10.2 documentation) -- 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-1969) Tools Guide: Spelling errors in doc for ij show command
Tools Guide: Spelling errors in doc for ij show command --- Key: DERBY-1969 URL: http://issues.apache.org/jira/browse/DERBY-1969 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.3.0.0 Reporter: Øystein Grøvlen Priority: Trivial SHOW TABLES will diplay ... For SHOW VIEWS: If IN schemaName is specified, the tables in the given schema are displayed. I guess it should say views not tables. -- 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
Show commands are not orthogonal
I find it strange that while SHOW INDEXES, SHOW PROCEDURES, and SHOW SYNONYMS by default list all corresponding objects in the database, SHOW TABLES and SHOW VIEWS by default only list the corresponding objects in the current schema. Would it not be better if all commands behaved the same way? Are there reasons for not changing this? I also find it a bit strange that SHOW VIEWS uses the heading TABLE_NAME and not VIEW_NAME. -- Øystein
[jira] Updated: (DERBY-1535) Trial 2 for DERBY-550, improve use of Engine from NetworkServer and reduce memory usage
[ http://issues.apache.org/jira/browse/DERBY-1535?page=all ] Tomohito Nakayama updated DERBY-1535: - Attachment: DERBY-1535_2.patch * Description of the patch Replacing call of setByte() to call of setBinaryInputStream(), which was room to improvement in DERBY-1559. * Test result Execute derbyall and found no error. Trial 2 for DERBY-550, improve use of Engine from NetworkServer and reduce memory usage --- Key: DERBY-1535 URL: http://issues.apache.org/jira/browse/DERBY-1535 Project: Derby Issue Type: Sub-task Components: Network Server Reporter: Tomohito Nakayama Assigned To: Tomohito Nakayama Attachments: DERBY-1513_1535.patch, DERBY-1513_1535_2.patch, DERBY-1513_1535_rollback.patch, DERBY-1535.patch, DERBY-1535_2.patch, serverMemoryUsage.xls, serverMemoryUsage_1513_1535.xls Through DERBY-1513, Trial 1 for DERBY-550, it was suggested that NetworkServer seems to use Engine inefficiently and use too much of memory. This task try to improve the use of Engine from NetworkServer and try to reduce memory usage. -- 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: [VOTE] Fernanda Pizzorno as a Derby committer
Daniel John Debrunner wrote: I propose a vote for Fernanda Pizzorno as a Derby committer. +1 Dan.
[jira] Commented: (DERBY-1962) Convert jdbcapi/resultsetJdbc30.java to junit
[ http://issues.apache.org/jira/browse/DERBY-1962?page=comments#action_12442913 ] Daniel John Debrunner commented on DERBY-1962: -- If the test is only to run under embedded it should contain comments indicating why that is the case. Makes it easier for folks looking at the code later to figure out why it's not being run with client/server. Convert jdbcapi/resultsetJdbc30.java to junit - Key: DERBY-1962 URL: http://issues.apache.org/jira/browse/DERBY-1962 Project: Derby Issue Type: Sub-task Components: Test Reporter: Fernanda Pizzorno Assigned To: Fernanda Pizzorno Attachments: derby-1962.diff, derby-1962.stat -- 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: [VOTE] Fernanda Pizzorno as a Derby committer
Daniel John Debrunner [EMAIL PROTECTED] writes: I propose a vote for Fernanda Pizzorno as a Derby committer. +1 -- Knut Anders
Re: [VOTE] Fernanda Pizzorno as a Derby committer
+1 Daniel John Debrunner wrote: I propose a vote for Fernanda Pizzorno as a Derby committer. Fernanda worked on the implementation of scrollable updateable result sets and has also submitted patches to fix a number of issues. Fernanda is also currently jumping into converting tests to JUnit. Please vote +1 if you agree Fernanda should be a committer. Vote will run for a week. Thanks, Dan.
[jira] Commented: (DERBY-1001) Rewrite 'store/encryptionKey.sql' to a JUnit test
[ http://issues.apache.org/jira/browse/DERBY-1001?page=comments#action_12442918 ] Kristian Waagan commented on DERBY-1001: I might be confused, so I'll write out my thoughts and people can correct me. Since the path we need (read) access to is specified by the user in the connection string, I thought these permissions should not be granted to the Derby codebase, but rather for the application codebase using Derby. This would mean the application would have to do a doPrivileged when restoring/creating the database. [1] says: ... the call to doPrivileged should be made in the code that wants to enable its privileges. After the connection has been made, Derby's core permissions should be sufficient to ensure normal operation again. However, when running the network server, the approach mentioned above will not work, and permissions to the backup locations would have to be granted to derby.jar, not the application code. Then adding doPrivileged-blocks to the derby.jar codebase is reasonable. I think also I forgot that our policy file is just an example and for a specific use (for instance running the tests). For a concrete deployment, the user/administrator must add the proper permissions. The fact that Derby was able to write the backup, but not read it, must be attributed to more extensive usage of doPrivileged-blocks in one code path over the other. I suppose the default policy file and the tests must be written to be compatible with each other, and I think they will be if we add more doPrivileged-blocks. My initial concern was why other actions in the area are wrapped in doPrivileged-blocks, while the backupRoot.exists() is not. Thought there could be was a reason for that. Does this make any sense? [1] http://java.sun.com/j2se/1.5.0/docs/guide/security/doprivileged.html Rewrite 'store/encryptionKey.sql' to a JUnit test - Key: DERBY-1001 URL: http://issues.apache.org/jira/browse/DERBY-1001 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.2.1.6 Reporter: Kristian Waagan Assigned To: Kristian Waagan Priority: Minor This test has failed on Solaris10 for a long time, due to issues with the default security provider on this OS. See DERBY-788 for details. I consider rewriting this test as interresting because it allows us to see how things can be done in the JUnit way. 1) Run test with multiple encryption algorithms with minimal test code duplication. 2) Special handling of exceptions for specific providers (PCKS11-Solaris). The rewritten test might cause some discussion on how we want to handle the issues mentioned above. -- 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: [VOTE] Fernanda Pizzorno as a Derby committer
+1 Daniel John Debrunner wrote: I propose a vote for Fernanda Pizzorno as a Derby committer. Fernanda worked on the implementation of scrollable updateable result sets and has also submitted patches to fix a number of issues. Fernanda is also currently jumping into converting tests to JUnit. Please vote +1 if you agree Fernanda should be a committer. Vote will run for a week. Thanks, Dan. -- /* Tomohito Nakayama [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html */
Re: [VOTE] Fernanda Pizzorno as a Derby committer
Daniel John Debrunner wrote: Please vote +1 if you agree Fernanda should be a committer. +1 -- Øystein
[jira] Updated: (DERBY-1610) Resolve difference of type compatibility between Embedded and NetworkServer/NetworkDriver
[ http://issues.apache.org/jira/browse/DERBY-1610?page=all ] Tomohito Nakayama updated DERBY-1610: - Derby Info: [Existing Application Impact, Release Note Needed] (was: [Release Note Needed]) Resolve difference of type compatibility between Embedded and NetworkServer/NetworkDriver - Key: DERBY-1610 URL: http://issues.apache.org/jira/browse/DERBY-1610 Project: Derby Issue Type: Bug Components: Network Server, Network Client Reporter: Tomohito Nakayama Assigned To: Tomohito Nakayama Attachments: derby-1610-jdk16.diff, DERBY-1610.diff, DERBY-1610_2.diff, DERBY-1610_3.diff, DERBY-1610_4.diff, DERBY-1610_5.diff, DERBY-1610_6.patch, DERBY-1610_7.patch, DERBY-1610_7_regressionfix.patch, DERBY-1610_7_regressionfix_2.patch, DERBY-1610_7_regressionfix_2_2.patch, DERBY-1610_7_regressionfix_2_3.patch, parameterMapping.diff, parameterMapping.diff, parameterMapping.diff.betweenEmbedded_and_NetworkServerNetworkClient, parameterMapping.out.7.diff, parameterMapping.out.diff, parameterMapping_3.diff, TestNullChar.java, TestTypeCompatibility.java, XCL12.diff There exists difference of type compatibility between Embedded and NetworkServer/NetworkClient. This issue tries to resolve it. -- 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-187) Starting derby network server as a service in Win OS
[ http://issues.apache.org/jira/browse/DERBY-187?page=comments#action_12442935 ] Tomohito Nakayama commented on DERBY-187: - I posted question above to [EMAIL PROTECTED] Starting derby network server as a service in Win OS Key: DERBY-187 URL: http://issues.apache.org/jira/browse/DERBY-187 Project: Derby Issue Type: New Feature Components: Services Affects Versions: 10.0.2.1 Environment: OS will be only any flavour of Windows. Reporter: Amit Handa Priority: Minor The Derby Network Server Database could be started/stopped as a service in Windows OS. This may involve updating the win registry. Further work needs to be done to understand what all will it require to do such a thing. I am putting below Andrew McIntyre's comments if they can help in getting a solution to this problem. If you would like to see this functionality added, please add a JIRA entry for it. The easiest way to do this would be to provide a registry key file for Derby Network Server and provide instructions on how to install it as a Windows service using instsrv and srvany. However, we obviously can't redistribute those two utilities, but it would be nice to provide all the parts to the solution. So, a little searching turned up this public domain srvany replacement: http://iain.cx/src/nssm/ I haven't tried it, but I suggest trying it out to see how well it works. -- 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: [VOTE] Fernanda Pizzorno as a Derby committer
On 10/17/06, Daniel John Debrunner [EMAIL PROTECTED] wrote: Please vote +1 if you agree Fernanda should be a committer. +1 Deepa
Re: [VOTE] Fernanda Pizzorno as a Derby committer
Daniel John Debrunner [EMAIL PROTECTED] writes: I propose a vote for Fernanda Pizzorno as a Derby committer. Fernanda worked on the implementation of scrollable updateable result sets and has also submitted patches to fix a number of issues. Fernanda is also currently jumping into converting tests to JUnit. Please vote +1 if you agree Fernanda should be a committer. Vote will run for a week. +1 -- dt However, experience shows that for many people and many applications a dose of paranoia is reasonable - Bjarne Stroustrup
[jira] Assigned: (DERBY-1967) UNION (ALL) contraint violation problem
[ http://issues.apache.org/jira/browse/DERBY-1967?page=all ]
Yip Ng reassigned DERBY-1967:
-
Assignee: Yip Ng
UNION (ALL) contraint violation problem
---
Key: DERBY-1967
URL: http://issues.apache.org/jira/browse/DERBY-1967
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.2.1.6, 10.1.3.1
Environment: derby v10.1.3.1 and v10.2.1.6 on linux (FC5), jdk
1.5.0_06-b05
and jdk 1.6.0-rc-b99.
Reporter: Radu Radutiu
Assigned To: Yip Ng
The following simple test case gives an error:
create table a (f1 varchar(10));
create table b (f2 varchar(10));
insert into b values('test');
select nullif('x','x') as f0, f1 from a
union all
select nullif('x','x') as f0, nullif('x','x') as f1 from b;
ERROR 23502: Column 'F0' cannot accept a NULL value.
SQLState(23502) vendor code(3)
However the following works ok:
drop table a;
drop table b;
create table a (f1 int);
create table b (f2 int);
insert into b values(1);
select nullif('x','x') as f0, f1 from a
union all
select nullif('x','x') as f0, nullif(1,1) as f1 from b;
The test case is a simplification of a query generated by Hibernate
with the table per class inheritance strategy. Both queries work ok on
MSSQL and PostgreSQL. On Derby only the second query works, the first
one giving a contraint violation.
--
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: [VOTE] Fernanda Pizzorno as a Derby committer
On 10/17/06, Daniel John Debrunner [EMAIL PROTECTED] wrote: I propose a vote for Fernanda Pizzorno as a Derby committer.+1Yip
Re: [VOTE] Fernanda Pizzorno as a Derby committer
Daniel John Debrunner wrote: I propose a vote for Fernanda Pizzorno as a Derby committer. Please vote +1 if you agree Fernanda should be a committer. Vote will run for a week. +1 Army
Re: [VOTE] Fernanda Pizzorno as a Derby committer
Please vote +1 if you agree Fernanda should be a committer. +1 bryan
[jira] Commented: (DERBY-1967) UNION (ALL) contraint violation problem
[
http://issues.apache.org/jira/browse/DERBY-1967?page=comments#action_12442940 ]
A B commented on DERBY-1967:
I did some investigating around this and it appears that this query works in
10.1.2.1 but fails in 10.1.3 and later. I was eventually able to track it down
to the changes for DERBY-7. Before those changes were committed the query ran
without error; after that commit this query now fails. For what that's worth...
UNION (ALL) contraint violation problem
---
Key: DERBY-1967
URL: http://issues.apache.org/jira/browse/DERBY-1967
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.2.1.6, 10.1.3.1
Environment: derby v10.1.3.1 and v10.2.1.6 on linux (FC5), jdk
1.5.0_06-b05
and jdk 1.6.0-rc-b99.
Reporter: Radu Radutiu
Assigned To: Yip Ng
The following simple test case gives an error:
create table a (f1 varchar(10));
create table b (f2 varchar(10));
insert into b values('test');
select nullif('x','x') as f0, f1 from a
union all
select nullif('x','x') as f0, nullif('x','x') as f1 from b;
ERROR 23502: Column 'F0' cannot accept a NULL value.
SQLState(23502) vendor code(3)
However the following works ok:
drop table a;
drop table b;
create table a (f1 int);
create table b (f2 int);
insert into b values(1);
select nullif('x','x') as f0, f1 from a
union all
select nullif('x','x') as f0, nullif(1,1) as f1 from b;
The test case is a simplification of a query generated by Hibernate
with the table per class inheritance strategy. Both queries work ok on
MSSQL and PostgreSQL. On Derby only the second query works, the first
one giving a contraint violation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (11 issues) Subscriber: derby-dev Key Summary DERBY-1962 Convert jdbcapi/resultsetJdbc30.java to junit http://issues.apache.org/jira/browse/DERBY-1962 DERBY-1953 Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional http://issues.apache.org/jira/browse/DERBY-1953 DERBY-1895 Convert jdbcapi/blobclob4BLOB.java to Junit http://issues.apache.org/jira/browse/DERBY-1895 DERBY-1948 10.2 'Working with Derby' manual errors. http://issues.apache.org/jira/browse/DERBY-1948 DERBY-1951 Missing directory separator in path construction in 'NetworkServerTestSetup.setUp' http://issues.apache.org/jira/browse/DERBY-1951 DERBY-1938 Add support for setObject(arg, null) http://issues.apache.org/jira/browse/DERBY-1938 DERBY-1930 Move JDBC implementation notes into the published javadoc http://issues.apache.org/jira/browse/DERBY-1930 DERBY-1918 INCREMENT of IDENTITY column described as allowing a value of zero in reference manual http://issues.apache.org/jira/browse/DERBY-1918 DERBY-963 Allow user friendly string values for security mechanism in client connection url. http://issues.apache.org/jira/browse/DERBY-963 DERBY-1808 [PATCH] Inbuilt functions SIGN, SQRT, RAND, RANDOM, COSH, SINH and TANH http://issues.apache.org/jira/browse/DERBY-1808 DERBY-646 In-memory backend storage support http://issues.apache.org/jira/browse/DERBY-646
Workaround for running JUnit tests with the GUI runners (was: Re: [junit] Making progess faster towards a pure Junit world)
[EMAIL PROTECTED] wrote: Kristian Waagan [EMAIL PROTECTED] writes: Daniel John Debrunner wrote: [ snip - progress towards a pure JUnit world ] Should it be possible to run junit tests with ALL the junit runners, or just with junit.textui.TestRunner? With the current trunk I able to run org.apache.derbyTesting.functionTests.tests.jdbcapi._Suite successfully with junit.textui.TestRunner (if I set derby.system.home), but with junit.awtui.TestRunner or junit.swingui.TestRunner the first test fails with java.lang.ExceptionInInitializerError at org.apache.derbyTesting.junit.TestConfiguration.defaultSecurityManagerSetup(TestConfiguration.java:667) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:73) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) Caused by: java.lang.NullPointerException at org.apache.derbyTesting.junit.SecurityManagerSetup.determineClasspath(SecurityManagerSetup.java:218) at org.apache.derbyTesting.junit.SecurityManagerSetup.clinit(SecurityManagerSetup.java:56) ... 19 more and the following tests fail with java.lang.NoClassDefFoundError: Could not initialize class org.apache.derbyTesting.junit.SecurityManagerSetup at org.apache.derbyTesting.junit.TestConfiguration.defaultSecurityManagerSetup(TestConfiguration.java:667) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:73) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) Should I create a JIRA for this? Hi Dyre, I think you can create a Jira for this, if you haven't already. The problem is that the GUI runners are using a custom classload to allow for dynamic reloading of the test classes. It defeats the getURL method in SecurityManagerSetup, seemingly by returning an empty/null (the object itself isn't null) ProtectionDomain object. This finally leads to the URL object extracted being null, which causes the NPE. A workaround is to specify the -noloading option for the runner, like this: java -classpath X junit.swingui.TestRunner -noloading org.apache.derbyTesting... If you do this, you must restart the GUI if you recompile the test classes. We should investigate this and see if we can get it working without specifying the -noloading argument. -- Kristian
[jira] Closed: (DERBY-1839) Doc Review Updates - Ref Manual
[ http://issues.apache.org/jira/browse/DERBY-1839?page=all ] Laura Stewart closed DERBY-1839. Resolution: Fixed All of the doc review comments on the Ref Guide that could be fixed for 10.2.1.6 were implemented. The remaining comments have open Jira issues. Therefore this issue can be closed. Doc Review Updates - Ref Manual --- Key: DERBY-1839 URL: http://issues.apache.org/jira/browse/DERBY-1839 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.2.1.6 Reporter: Laura Stewart Assigned To: Laura Stewart Fix For: 10.2.1.8, 10.2.2.0, 10.3.0.0 Attachments: 1839_SQLstatements.diff, derby1839_functions1.diff, derby1839_functions1.zip, derby1839_functions2.diff, derby1839_functions2_html.zip, derby1839_functions3.diff, derby1839_functions_html3.zip, derby1839_SQLstatement_4.diff, derby1839_SQLstatements2.diff, derby1839_SQLstatements2_html.zip, derby1839_SQLstatements3.diff, derby1839_SQLstatements3_html.zip, derby1839_SQLstatements4_html.zip, derby1839_SQLstatements_html.zip, derby1839_TANCEILfunctions.diff, derby1839_TANCEILfunctions_html.zip, derby1839_XML+functions_1.diff, derby1839_XML+functions_2.diff, derby1839_XML+functions_html1.zip, derby1839_XML+functions_html2.zip This JIRA issue will be used to track all of the issues found in the 10.2 doc review of the Reference Manual. -- 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 Report - 464529 - Sun DBTG
[Auto-generated mail] ** 464529/2006-10-16 18:00:07 MEST ** Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 0688688 0 107.03% lin 0688688 0 111.71% sol 0688688 097.33% solN+1 0688688 0 108.29% sparc NA NA NANA win Details in http://www.multinet.no/~solberg/public/Apache/Daily/jvm1.6/Limited/testSummary-464529.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Daily/Failures/jvm1.6/464529.html *Jvm: 1.5* 0676676 2 106.14% lin NA NA NANA sol 0676676 297.68% solN+1 0676676 2 107.33% sparc NA NA NANA win Details in http://www.multinet.no/~solberg/public/Apache/Daily/jvm1.5/Limited/testSummary-464529.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Daily/Failures/jvm1.5/464529.html *Jvm: 1.4* 0670670 4 106.49% lin 0670670 4 110.42% sol 0670670 498.06% solN+1 0670670 4 107.66% sparc NA NA NANA win Details in http://www.multinet.no/~solberg/public/Apache/Daily/jvm1.4/Limited/testSummary-464529.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Daily/Failures/jvm1.4/464529.html --- Changes in http://www.multinet.no/~solberg/public/Apache/Daily/UpdateInfo/464529.txt ( All results in http://www.multinet.no/~solberg/public/Apache/Daily/index.html )
[jira] Closed: (DERBY-1954) Update sysinfo output documentation in Tools and Utilities Guide
[ http://issues.apache.org/jira/browse/DERBY-1954?page=all ] Laura Stewart closed DERBY-1954. Resolution: Fixed Update sysinfo output documentation in Tools and Utilities Guide Key: DERBY-1954 URL: http://issues.apache.org/jira/browse/DERBY-1954 Project: Derby Issue Type: Bug Components: Documentation Reporter: Laura Stewart Assigned To: Laura Stewart Fix For: 10.2.1.8, 10.3.0.0 Attachments: derby1954_1.diff, derby1954_html1.zip Section = sysinfo File = rtoolssysinfo1002629.html In the example section, the new text = With derby.jar and derbytools.jar in your classpath the output from running the sysinfo command is shown below. $ java org.apache.derby.tools.sysinfo -- 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: [VOTE] Fernanda Pizzorno as a Derby committer
+1--Andreas
[jira] Commented: (DERBY-1967) UNION (ALL) contraint violation problem
[
http://issues.apache.org/jira/browse/DERBY-1967?page=comments#action_12442949 ]
Yip Ng commented on DERBY-1967:
---
Thanks Army, I just found the problem and running my patch against derbyall
currently. Some explanation of the problem:
In the bind phase of ConditionalNode (NULLIF), the CAST node is generated on
top of the untyped NULL and it gets the data type descriptor(DTD) of the left
operand. However, the CAST node should have DTD where its value can be
nullable.
BinaryComparisonOperatorNode bcon = (BinaryComparisonOperatorNode)testCondition;
QueryTreeNode cast = getNodeFactory().getNode(
C_NodeTypes.CAST_NODE,
thenElseList.elementAt(0),
bcon.getLeftOperand().getTypeServices(), === not nullable!
getContextManager());
The second query:
select nullif('x','x') as f0, f1 from a
union all
select nullif('x','x') as f0, nullif(1,1) as f1 from b;
works because it didn't generate a NormalizedResultSet on top of the PRN on the
right hand side of the union since the datatype and length matches. So it
didn't hit the path where it does additional checking at execution time.
For the first query:
select nullif('x','x') as f0, f1 from a
union all
select nullif('x','x') as f0, nullif('x','x') as f1 from b;
The union result column's length does not match with the right hand side result
column, so it generated a NormalizedResultSet on top of the RHS of the union.
When the system retrieves the row from NormalizedResultSet at execution time,
the normalize method is called on the DTD and checks if the source is NULL and
whether its DTD is not nullable. In this case, the SQLSTATE 23502 is thrown.
UNION (ALL) contraint violation problem
---
Key: DERBY-1967
URL: http://issues.apache.org/jira/browse/DERBY-1967
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.2.1.6, 10.1.3.1
Environment: derby v10.1.3.1 and v10.2.1.6 on linux (FC5), jdk
1.5.0_06-b05
and jdk 1.6.0-rc-b99.
Reporter: Radu Radutiu
Assigned To: Yip Ng
The following simple test case gives an error:
create table a (f1 varchar(10));
create table b (f2 varchar(10));
insert into b values('test');
select nullif('x','x') as f0, f1 from a
union all
select nullif('x','x') as f0, nullif('x','x') as f1 from b;
ERROR 23502: Column 'F0' cannot accept a NULL value.
SQLState(23502) vendor code(3)
However the following works ok:
drop table a;
drop table b;
create table a (f1 int);
create table b (f2 int);
insert into b values(1);
select nullif('x','x') as f0, f1 from a
union all
select nullif('x','x') as f0, nullif(1,1) as f1 from b;
The test case is a simplification of a query generated by Hibernate
with the table per class inheritance strategy. Both queries work ok on
MSSQL and PostgreSQL. On Derby only the second query works, the first
one giving a contraint violation.
--
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-1951) Missing directory separator in path construction in 'NetworkServerTestSetup.setUp'
[ http://issues.apache.org/jira/browse/DERBY-1951?page=comments#action_12442951 ] Kristian Waagan commented on DERBY-1951: Anybody planning to commit or further review this? Although the issue is simple to work around, the patch is also simple and would be convenient to get in. Missing directory separator in path construction in 'NetworkServerTestSetup.setUp' -- Key: DERBY-1951 URL: http://issues.apache.org/jira/browse/DERBY-1951 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.3.0.0 Reporter: Kristian Waagan Assigned To: Kristian Waagan Attachments: derby-1951-1a.diff, derby-1951-1b.diff When constructing the path for the server output file, the directory separator (typically '/') is omitted, causing a security violation when running under the security manager. Here's a sample stack trace for a JUnit run: 1) AllPackagesjava.security.AccessControlException: access denied (java.io.FilePermission /some/pathserverConsoleOutput.log write) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269) at java.security.AccessController.checkPermission(AccessController.java:401) at java.lang.SecurityManager.checkPermission(SecurityManager.java:524) at java.lang.SecurityManager.checkWrite(SecurityManager.java:954) at java.io.FileOutputStream.init(FileOutputStream.java:169) at java.io.FileOutputStream.init(FileOutputStream.java:70) at org.apache.derbyTesting.junit.NetworkServerTestSetup$1.run(NetworkServerTestSetup.java:72 ) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derbyTesting.junit.NetworkServerTestSetup.setUp(NetworkServerTestSetup.java:65 ) at junit.extensions.TestSetup$1.protect(TestSetup.java:18) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) -- 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: [VOTE] Fernanda Pizzorno as a Derby committer
Daniel John Debrunner wrote: I propose a vote for Fernanda Pizzorno as a Derby committer. +1 Sunitha.
Re: [VOTE] Fernanda Pizzorno as a Derby committer
Daniel John Debrunner [EMAIL PROTECTED] writes: I propose a vote for Fernanda Pizzorno as a Derby committer. +1 Dag
[junit] Naming TestSuite objects
Hi, I think it would be a nice habit to give the TestSuite objects reasonable names. It makes the test hierarchy look better in the GUI runners. A generic/descriptive name could also be added to the suites created by methods in TestConfiguration. -- Kristian
[jira] Updated: (DERBY-1967) UNION (ALL) contraint violation problem
[ http://issues.apache.org/jira/browse/DERBY-1967?page=all ]
Yip Ng updated DERBY-1967:
--
Attachment: derby1967-trunk-stat01.txt
derby1967-trunk-diff01.txt
Attaching patch derby1967-trunk-diff01.txt for review. derbyall still running.
Will post result when it completes.
UNION (ALL) contraint violation problem
---
Key: DERBY-1967
URL: http://issues.apache.org/jira/browse/DERBY-1967
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.2.1.6, 10.1.3.1
Environment: derby v10.1.3.1 and v10.2.1.6 on linux (FC5), jdk
1.5.0_06-b05
and jdk 1.6.0-rc-b99.
Reporter: Radu Radutiu
Assigned To: Yip Ng
Attachments: derby1967-trunk-diff01.txt, derby1967-trunk-stat01.txt
The following simple test case gives an error:
create table a (f1 varchar(10));
create table b (f2 varchar(10));
insert into b values('test');
select nullif('x','x') as f0, f1 from a
union all
select nullif('x','x') as f0, nullif('x','x') as f1 from b;
ERROR 23502: Column 'F0' cannot accept a NULL value.
SQLState(23502) vendor code(3)
However the following works ok:
drop table a;
drop table b;
create table a (f1 int);
create table b (f2 int);
insert into b values(1);
select nullif('x','x') as f0, f1 from a
union all
select nullif('x','x') as f0, nullif(1,1) as f1 from b;
The test case is a simplification of a query generated by Hibernate
with the table per class inheritance strategy. Both queries work ok on
MSSQL and PostgreSQL. On Derby only the second query works, the first
one giving a contraint violation.
--
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-1967) UNION (ALL) contraint violation problem
[ http://issues.apache.org/jira/browse/DERBY-1967?page=all ]
Yip Ng updated DERBY-1967:
--
Derby Info: [Patch Available]
UNION (ALL) contraint violation problem
---
Key: DERBY-1967
URL: http://issues.apache.org/jira/browse/DERBY-1967
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.2.1.6, 10.1.3.1
Environment: derby v10.1.3.1 and v10.2.1.6 on linux (FC5), jdk
1.5.0_06-b05
and jdk 1.6.0-rc-b99.
Reporter: Radu Radutiu
Assigned To: Yip Ng
Attachments: derby1967-trunk-diff01.txt, derby1967-trunk-stat01.txt
The following simple test case gives an error:
create table a (f1 varchar(10));
create table b (f2 varchar(10));
insert into b values('test');
select nullif('x','x') as f0, f1 from a
union all
select nullif('x','x') as f0, nullif('x','x') as f1 from b;
ERROR 23502: Column 'F0' cannot accept a NULL value.
SQLState(23502) vendor code(3)
However the following works ok:
drop table a;
drop table b;
create table a (f1 int);
create table b (f2 int);
insert into b values(1);
select nullif('x','x') as f0, f1 from a
union all
select nullif('x','x') as f0, nullif(1,1) as f1 from b;
The test case is a simplification of a query generated by Hibernate
with the table per class inheritance strategy. Both queries work ok on
MSSQL and PostgreSQL. On Derby only the second query works, the first
one giving a contraint violation.
--
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-1951) Missing directory separator in path construction in 'NetworkServerTestSetup.setUp'
[ http://issues.apache.org/jira/browse/DERBY-1951?page=all ] Kristian Waagan closed DERBY-1951. -- Missing directory separator in path construction in 'NetworkServerTestSetup.setUp' -- Key: DERBY-1951 URL: http://issues.apache.org/jira/browse/DERBY-1951 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.3.0.0 Reporter: Kristian Waagan Assigned To: Kristian Waagan Fix For: 10.3.0.0 Attachments: derby-1951-1a.diff, derby-1951-1b.diff When constructing the path for the server output file, the directory separator (typically '/') is omitted, causing a security violation when running under the security manager. Here's a sample stack trace for a JUnit run: 1) AllPackagesjava.security.AccessControlException: access denied (java.io.FilePermission /some/pathserverConsoleOutput.log write) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269) at java.security.AccessController.checkPermission(AccessController.java:401) at java.lang.SecurityManager.checkPermission(SecurityManager.java:524) at java.lang.SecurityManager.checkWrite(SecurityManager.java:954) at java.io.FileOutputStream.init(FileOutputStream.java:169) at java.io.FileOutputStream.init(FileOutputStream.java:70) at org.apache.derbyTesting.junit.NetworkServerTestSetup$1.run(NetworkServerTestSetup.java:72 ) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derbyTesting.junit.NetworkServerTestSetup.setUp(NetworkServerTestSetup.java:65 ) at junit.extensions.TestSetup$1.protect(TestSetup.java:18) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) -- 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-1951) Missing directory separator in path construction in 'NetworkServerTestSetup.setUp'
[ http://issues.apache.org/jira/browse/DERBY-1951?page=all ] Kristian Waagan resolved DERBY-1951. Fix Version/s: 10.3.0.0 Resolution: Invalid Derby Info: (was: [Patch Available]) This problem no longer exists. The code was changed in revision 464785 by DERBY-1952. Missing directory separator in path construction in 'NetworkServerTestSetup.setUp' -- Key: DERBY-1951 URL: http://issues.apache.org/jira/browse/DERBY-1951 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.3.0.0 Reporter: Kristian Waagan Assigned To: Kristian Waagan Fix For: 10.3.0.0 Attachments: derby-1951-1a.diff, derby-1951-1b.diff When constructing the path for the server output file, the directory separator (typically '/') is omitted, causing a security violation when running under the security manager. Here's a sample stack trace for a JUnit run: 1) AllPackagesjava.security.AccessControlException: access denied (java.io.FilePermission /some/pathserverConsoleOutput.log write) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269) at java.security.AccessController.checkPermission(AccessController.java:401) at java.lang.SecurityManager.checkPermission(SecurityManager.java:524) at java.lang.SecurityManager.checkWrite(SecurityManager.java:954) at java.io.FileOutputStream.init(FileOutputStream.java:169) at java.io.FileOutputStream.init(FileOutputStream.java:70) at org.apache.derbyTesting.junit.NetworkServerTestSetup$1.run(NetworkServerTestSetup.java:72 ) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derbyTesting.junit.NetworkServerTestSetup.setUp(NetworkServerTestSetup.java:65 ) at junit.extensions.TestSetup$1.protect(TestSetup.java:18) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) -- 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: [VOTE] Fernanda Pizzorno as a Derby committer
+1! On 10/17/06, Daniel John Debrunner [EMAIL PROTECTED] wrote: I propose a vote for Fernanda Pizzorno as a Derby committer. Fernanda worked on the implementation of scrollable updateable result sets and has also submitted patches to fix a number of issues. Fernanda is also currently jumping into converting tests to JUnit. Please vote +1 if you agree Fernanda should be a committer. Vote will run for a week. Thanks, Dan.
Some JUnit tests now split out from old harness and do not run as part of derbyall
As discussed and recorded in DERBY-1952 I have split some of the JUnit tests out so that they are *no longer* run under the old test harness and hence are *not* part of derbyall. (on the trunk). A top-level JUnit test (suite) exists that runs all the tests that were removed from derbyall, the test's name is: org.apache.derbyTesting.functionTests.suites.All JUnit tests will continue to be added so that they run under this All test and thus be removed from the old harness. Instructions on how to run this Junit test are in http://wiki.apache.org/db-derby/DerbyJUnitTesting with notes on the configuration setup and how to write suite() methods in http://wiki.apache.org/db-derby/DerbyJunitTestConfiguration I've been updating the wiki so that I think it is up to date with the latest changes. I would encourage those that regularly run nightly or other testing to add this JUnit test into their framework. I'm sure there will be some issues getting it running on all the platforms but they should be easy to work through. There is more work to be done for some of the tests in All so that they also run in the client server by themselves, and I'm working on it for the tests in tests.jdbcapi. I'm also planning on laying out some form of a plan or work items that would move us completely over to JUnit. Dan. PS. The current runtime for this suite is a few minutes.
Re: [junit] Naming TestSuite objects
Kristian Waagan wrote: Hi, I think it would be a nice habit to give the TestSuite objects reasonable names. It makes the test hierarchy look better in the GUI runners. A generic/descriptive name could also be added to the suites created by methods in TestConfiguration. +1 to both, I never knew how those names were used, now it makes sense to give them names. Dan.
[jira] Commented: (DERBY-1897) junit test jdbcapi/_Suite fails with wctme5.7_foundation (j9 -jcl:foun) with NoClassDefFoundError: javax.sql.PooledConnection
[ http://issues.apache.org/jira/browse/DERBY-1897?page=comments#action_12442977 ] Myrna van Lunteren commented on DERBY-1897: --- The same problem occurs without the 'old' test harness, i.e. when I run: j9 -jcl:foun10 -Xbootclasspath/a:c:\wctme5.7\ive\lib\jdbc.jar junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.jdbcapi._Suite I see the same error: Failed to invoke suite():java.lang.NoClassDefFoundError: javax.sql.PooledConnection In actual fact, indeed the javax.sql.PooledConnection isn't in the jdbc.jar I have for/from this product. Should it be there? Myrna junit test jdbcapi/_Suite fails with wctme5.7_foundation (j9 -jcl:foun) with NoClassDefFoundError: javax.sql.PooledConnection - Key: DERBY-1897 URL: http://issues.apache.org/jira/browse/DERBY-1897 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.2.1.6, 10.3.0.0 Environment: windows with wctme5.7's jcl:foun implementation of JSR 169 - j9_foundation or wctme5.7_foundation. Reporter: Myrna van Lunteren Priority: Minor Running the jdbcapi/_Suite with the test harness with wctme5.7_foundation results in the following error: 0 add Failed to invoke suite():java.lang.NoClassDefFoundError: javax.sql.PooledConnection Test Failed. This is the only information available. This error is especially strange because wctme5.7_foundation should support javax.sql.PooledConnection (in contrast to wctme5.7, which is not JDBC3.0 complient). -- 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: [VOTE] Fernanda Pizzorno as a Derby committer
+1 On 10/17/06, Daniel John Debrunner [EMAIL PROTECTED] wrote: I propose a vote for Fernanda Pizzorno as a Derby committer.Fernanda worked on the implementation of scrollable updateable result sets and has also submitted patches to fix a number of issues. Fernandais also currently jumping into converting tests to JUnit.Please vote +1 if you agree Fernanda should be a committer.Vote will run for a week. Thanks,Dan.
[jira] Created: (DERBY-1970) Add framework for performance tests in derby using Junit.
Add framework for performance tests in derby using Junit. -- Key: DERBY-1970 URL: http://issues.apache.org/jira/browse/DERBY-1970 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.3.0.0 Reporter: Sunitha Kambhampati Add a framework for performance tests to be added in derby. Some goals are : -- use Junit, thus will serve double duty as both functional tests as well as performance tests. -- builds upon the existing infrastructure available to run functional tests * for example, getting connections is handled in a single way allowing the performance tests to run with J2ME, DriverManager, DataSource, single leg of an XA transaction etc. -- be able to run using Junit directly. -- easy for developers to add these tests and run them. -- 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: [VOTE] Fernanda Pizzorno as a Derby committer
Daniel John Debrunner wrote: I propose a vote for Fernanda Pizzorno as a Derby committer. +1 -suresh
Re: [VOTE] Fernanda Pizzorno as a Derby committer
Daniel John Debrunner wrote: I propose a vote for Fernanda Pizzorno as a Derby committer. Fernanda worked on the implementation of scrollable updateable result sets and has also submitted patches to fix a number of issues. Fernanda is also currently jumping into converting tests to JUnit. Please vote +1 if you agree Fernanda should be a committer. Vote will run for a week. +1 -jean
Issues with Forrest/Derby Web site (Was: Re: Proposal - Doc Process Improvements)
I am having some difficulties following the setup instructions for forrest.. should I ask these questions on derby-dev or ??? Is there a user list for forrest? On 10/6/06, Jean T. Anderson [EMAIL PROTECTED] wrote: ... (snip) Your recommendation sounds good. The http://db.apache.org/derby/manuals/dita.html link you mention is part of the forrest-generated web site. The source for that particular file is at https://svn.apache.org/repos/asf/db/derby/site/trunk/src/documentation/content/xdocs/manuals/dita.xml . Information on how to checkout and build the web site is at http://db.apache.org/derby/papers/derby_web.html . Web site instructions also need more and better information. For example, they need to explain that the files under http://db.apache.org/derby/docs are actually generated separately from the web site and the web site simply points to those files hopefully achieving an integrated experience for the end user. -jean -- Laura Stewart
[jira] Commented: (DERBY-1897) junit test jdbcapi/_Suite fails with wctme5.7_foundation (j9 -jcl:foun) with NoClassDefFoundError: javax.sql.PooledConnection
[ http://issues.apache.org/jira/browse/DERBY-1897?page=comments#action_12442995 ] Deepa Remesh commented on DERBY-1897: - I too don't see this class in the jdbc.jar for wctme5.7/foundation. JSR169 is a subset of JDBC3.0. javax.sql.PooledConnection is not listed in the JSR169 API here: http://developers.sun.com/techtopics/mobility/configurations/articles/cdc/jdbc/ I think we will have to exclude tests which use above class from running in this environment. junit test jdbcapi/_Suite fails with wctme5.7_foundation (j9 -jcl:foun) with NoClassDefFoundError: javax.sql.PooledConnection - Key: DERBY-1897 URL: http://issues.apache.org/jira/browse/DERBY-1897 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.2.1.6, 10.3.0.0 Environment: windows with wctme5.7's jcl:foun implementation of JSR 169 - j9_foundation or wctme5.7_foundation. Reporter: Myrna van Lunteren Priority: Minor Running the jdbcapi/_Suite with the test harness with wctme5.7_foundation results in the following error: 0 add Failed to invoke suite():java.lang.NoClassDefFoundError: javax.sql.PooledConnection Test Failed. This is the only information available. This error is especially strange because wctme5.7_foundation should support javax.sql.PooledConnection (in contrast to wctme5.7, which is not JDBC3.0 complient). -- 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: Discussion: Feedback needed on the Documentation Review process
Comments inline. Regards, -Rajesh Laura Stewart wrote: For the 10.2 Documentation Review process, a wiki was used to log comments and track the status of those comments. http://wiki.apache.org/db-derby/TenTwoDocReview The purpose of the review is to take a comprehensive look at the documentation. Because most documentation updates are made for an isolated bug or feature, the new content isn't always looked at from a broader, library perspective. The end of cycle documentation review enables the community to take a look at the documentation as a whole. As someone who implemented a large number of the comments, I am interested in hearing feedback on the process: What worked well and what needs to be improved in the documentation review process? Was the wiki a good way to conduct the reviews? Maybe it is the MoinMoin - Derby wiki that does not allow an easier way to edit tables, but I found adding/editing the pages not that friendly. Updating a JIRA issue seemed easier. So if we have to continue using the current wiki, maybe a JIRA issue for each manual could be easier, where reviewers can add the comments to. This issue can be closed if the majority of the comments are addressed and a new JIRA issue can be created, if needed, for any unaddressed ones. Did you understand how to log your comments? Thru discussions on the list it was made clear in the begining, so I did not have any issues. There were only a few people that participated in the review. What prevented more people from participating? I agree, would be interesting to find out. Anyways, I think at a minimum we can ensure that the doc review cannot be marked complete unless, for all the new features, we have sign-off from the respective contributors. Is the end of cycle the best time to perform the comprehensive review? Should the comprehensive review be performed at the beginning of a feature cycle? In the middle of a feature cycle? I think, to incorporate the newer feature docs, end of the cycle review seems to work. But if a start/mid cycle comprehensive review (without the new features) is initated, we will have to do another round - for the new features only. This can definitely help for some doc refinement/clean-up and may be workable if we all in the community decide to participate. Please provide your feedback so that the documentation review process can be improved. Thanks!
Re: Issues with Forrest/Derby Web site (Was: Re: Proposal - Doc Process Improvements)
Laura Stewart wrote: I am having some difficulties following the setup instructions for forrest.. should I ask these questions on derby-dev or ??? Is there a user list for forrest? It may be that some of your questions need to be directed to the forrest user list, but unless anyone objects I suggest you ask the questions here. That might help other derby developers likewise get involved with the web site. -jean
[jira] Commented: (DERBY-1953) Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
[
http://issues.apache.org/jira/browse/DERBY-1953?page=comments#action_12443000 ]
Suresh Thalamati commented on DERBY-1953:
-
Committed to trunk , revision 464970. Thanks Yip .
Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
-
Key: DERBY-1953
URL: http://issues.apache.org/jira/browse/DERBY-1953
Project: Derby
Issue Type: Improvement
Components: SQL
Affects Versions: 10.2.1.6
Environment: Any
Reporter: Yip Ng
Assigned To: Yip Ng
Priority: Minor
Attachments: derby1953-trunk-diff01.txt, derby1953-trunk-diff02.txt,
derby1953-trunk-diff03.txt, derby1953-trunk-diff04.txt,
derby1953-trunk-stat01.txt, derby1953-trunk-stat02.txt,
derby1953-trunk-stat03.txt, derby1953-trunk-stat04.txt
According to SQL:2003 standard, section 11.39 trigger definition, under
Syntax Rules item 8:
If neither FOR EACH ROW nor FOR EACH STATEMENT is specified, then FOR EACH
STATEMENT is implicit.
[ FOR EACH { ROW | STATEMENT } ]
--
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: Discussion: Feedback needed on the Documentation Review process
On 10/17/06, Rajesh Kartha [EMAIL PROTECTED] wrote: Comments inline. Regards, -Rajesh Was the wiki a good way to conduct the reviews? Maybe it is the MoinMoin - Derby wiki that does not allow an easier way to edit tables, but I found adding/editing the pages not that friendly. Updating a JIRA issue seemed easier. So if we have to continue using the current wiki, maybe a JIRA issue for each manual could be easier, where reviewers can add the comments to. This issue can be closed if the majority of the comments are addressed and a new JIRA issue can be created, if needed, for any unaddressed ones. Having a single issue per manual worked okay for me to submit patches, but I think that it would be harder to track individual comments and their status. Is there a way to create a sub issue or linked issue for individual comments? -- Laura Stewart
[jira] Commented: (DERBY-1965) NetworkServerControlImpl never closes the socket or streams it opens in setUpSocket.
[ http://issues.apache.org/jira/browse/DERBY-1965?page=comments#action_12442990 ] Mamta A. Satoor commented on DERBY-1965: Dan, I looked through the patch and wondered why do you do closeSocket(); in the finally block for methods sysinfo() and runtimeInfo() whereas in all the other places, closeSocket(); is not inside the finally block? Also, you probably didn't have any comments for the new method closeSocket() because it is self explanatory but I wonder if we should put something for this method since there is comment for the existing method setUpSocket(). Other than this, the patch looks good to me. NetworkServerControlImpl never closes the socket or streams it opens in setUpSocket. Key: DERBY-1965 URL: http://issues.apache.org/jira/browse/DERBY-1965 Project: Derby Issue Type: Improvement Components: Network Server Reporter: Daniel John Debrunner Assigned To: Daniel John Debrunner Priority: Minor Attachments: derby1965_diff.txt Every method that calls setUpSocket should have a call to a new closeSocket() method. -- 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-1971) Make TestConfiguration set descriptive names for TestSuite objects it instantiates
Make TestConfiguration set descriptive names for TestSuite objects it instantiates -- Key: DERBY-1971 URL: http://issues.apache.org/jira/browse/DERBY-1971 Project: Derby Issue Type: Improvement Components: Test Affects Versions: 10.3.0.0 Reporter: Kristian Waagan Priority: Minor Several JUnit tools make use of TestSuite.getName() to display test hierarchies and other information. An example is junit.swingui.TestRunner. Currently, the TestSuite objects generated by TestConfiguration are not given names. To improve readability and the level of information, descriptive named should be set. At a minimum, the associated framework should be indicated. Another point is whether the user set name (if any) of the root test suite should be propagated or not. -- 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-1953) Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
[ http://issues.apache.org/jira/browse/DERBY-1953?page=all ]
Yip Ng updated DERBY-1953:
--
Derby Info: (was: [Patch Available])
Unchecking patch available since it is already committed to trunk.
The ref manual needs to be updated with the updated syntax in CREATE TRIGGER
statement.
Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
-
Key: DERBY-1953
URL: http://issues.apache.org/jira/browse/DERBY-1953
Project: Derby
Issue Type: Improvement
Components: SQL
Affects Versions: 10.2.1.6
Environment: Any
Reporter: Yip Ng
Assigned To: Yip Ng
Priority: Minor
Attachments: derby1953-trunk-diff01.txt, derby1953-trunk-diff02.txt,
derby1953-trunk-diff03.txt, derby1953-trunk-diff04.txt,
derby1953-trunk-stat01.txt, derby1953-trunk-stat02.txt,
derby1953-trunk-stat03.txt, derby1953-trunk-stat04.txt
According to SQL:2003 standard, section 11.39 trigger definition, under
Syntax Rules item 8:
If neither FOR EACH ROW nor FOR EACH STATEMENT is specified, then FOR EACH
STATEMENT is implicit.
[ FOR EACH { ROW | STATEMENT } ]
--
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-1953) Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
[
http://issues.apache.org/jira/browse/DERBY-1953?page=comments#action_12443010 ]
Yip Ng commented on DERBY-1953:
---
Thanks Suresh, Bernt and Kristian for the review.
Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
-
Key: DERBY-1953
URL: http://issues.apache.org/jira/browse/DERBY-1953
Project: Derby
Issue Type: Improvement
Components: SQL
Affects Versions: 10.2.1.6
Environment: Any
Reporter: Yip Ng
Assigned To: Yip Ng
Priority: Minor
Attachments: derby1953-trunk-diff01.txt, derby1953-trunk-diff02.txt,
derby1953-trunk-diff03.txt, derby1953-trunk-diff04.txt,
derby1953-trunk-stat01.txt, derby1953-trunk-stat02.txt,
derby1953-trunk-stat03.txt, derby1953-trunk-stat04.txt
According to SQL:2003 standard, section 11.39 trigger definition, under
Syntax Rules item 8:
If neither FOR EACH ROW nor FOR EACH STATEMENT is specified, then FOR EACH
STATEMENT is implicit.
[ FOR EACH { ROW | STATEMENT } ]
--
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: [junit] Naming TestSuite objects
Daniel John Debrunner wrote: Kristian Waagan wrote: Hi, I think it would be a nice habit to give the TestSuite objects reasonable names. It makes the test hierarchy look better in the GUI runners. A generic/descriptive name could also be added to the suites created by methods in TestConfiguration. +1 to both, I never knew how those names were used, now it makes sense to give them names. I added DERBY-1971 for improving TestConfiguration. I consider an ongoing effort to be initiated to name suites in our existing JUnit tests :) The most straight-forward approach would be that the developer gives name to the suite, but there are other ways as well. For instance, TestConfiguration could probably force the name to be set to the name of the class from which the suite is created (won't work for all scenarios of course). As long as the name is more descriptive than [EMAIL PROTECTED], I'm happier... -- Kristian Dan.
[jira] Created: (DERBY-1972) Working With Derby needs some formatting fixes and other minor cleanup
Working With Derby needs some formatting fixes and other minor cleanup -- Key: DERBY-1972 URL: http://issues.apache.org/jira/browse/DERBY-1972 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.1.6 Reporter: Kim Haase Assigned To: Kim Haase Priority: Minor The Working With Derby book uses DITA tags in ways that are not always consistent with the usage in other books and that lead to some problems in the processed output. Some examples are the use of the varname tag in inappropriate places and the use of formatting tags within codeblock tags. There are also a few minor punctuation and syntax issues worth fixing. -- 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: [VOTE] Fernanda Pizzorno as a Derby committer
On 10/17/06, Daniel John Debrunner [EMAIL PROTECTED] wrote: Please vote +1 if you agree Fernanda should be a committer. Vote will run for a week. +1 andrew
Re: [VOTE] Fernanda Pizzorno as a Derby committer
Daniel John Debrunner wrote: I propose a vote for Fernanda Pizzorno as a Derby committer. +1 -- John
[jira] Assigned: (DERBY-1693) Out of Memory Error with derby.language.logStatementText=true
[ http://issues.apache.org/jira/browse/DERBY-1693?page=all ] Kristian Waagan reassigned DERBY-1693: -- Assignee: Kristian Waagan Having looked a little bit at this, I suggest adding (yet) another method to the DataValueDescriptor interface, say getTraceString(). The reason for this, is that today the method getString() is used to obtain the text logged to derby.log when derby.language.logStatementText is set to true. At the same time, this call is also used for getting the values of data types to do other operations. If getString() is changed to return a representation of the data that is only suitable for tracing, Derby will stop working. NetBeans counted 207 usages of the method. I tried changing getString(), and when executing a simple insert with a prepared statement, Derby went down miserably with a stack overflow error. I also tried adding the suggested getTraceString(), and things seemd to work (no LOB contents in derby.log and the test succeded). I think we can get away with a general implementation of getTraceString() that forwards to getString() in DataType and then write specific implementations for the types that require this (Clob and Blob). Have I overlooked something, or will this approach cause trouble? If I don't get pushback, I will create a patch for the suggested approach. Out of Memory Error with derby.language.logStatementText=true - Key: DERBY-1693 URL: http://issues.apache.org/jira/browse/DERBY-1693 Project: Derby Issue Type: Bug Affects Versions: 10.2.1.6 Environment: JVM INFO : java version 1.5.0_02 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09) Java HotSpot(TM) Client VM (build 1.5.0_02-b09, mixed mode) OS : Windows XP Professional Reporter: Manjula Kutty Assigned To: Kristian Waagan Priority: Minor While running a test with blobs and clobs of random size but not exceeding more than 5MB , with derby.language.logStatementText=true , The inserts are faling with out of memory error. Once that error occurs then the test loses all connections to the database. If I take off the derby.language.logStatementText=true property from derby.properties, the test runs fine. Here is the stack Trace java.lang.OutOfMemoryError: Java heap space ---SQLException Caught--- SQLState: XJ001 Severity: 0 Message: Java exception: 'Java heap space: java.lang.OutOfMemoryError'. java.lang.OutOfMemoryError: Java heap space java.sql.SQLException: No current connection. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExc eptionFactory.java:45) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:89) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:105) at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Util.java:209) at org.apache.derby.impl.jdbc.EmbedConnection.checkIfClosed(EmbedConnect ion.java:1351) at org.apache.derby.impl.jdbc.EmbedConnection.setupContextStack(EmbedCon nection.java:1529) at org.apache.derby.impl.jdbc.EmbedConnection.rollback(EmbedConnection.j ava:946) at com.ibm.db2j.tests.scenario.utils.DbTasks.insertMail(DbTasks.java:400 ) at com.ibm.db2j.tests.scenario.tasks.Refresh.insertMail(Refresh.java:62) at com.ibm.db2j.tests.scenario.tasks.Refresh.doWork(Refresh.java:43) at com.ibm.db2j.tests.scenario.tasks.Refresh.run(Refresh.java:21) -- 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
[VOTE] Fernanda Pizzorno as a Derby committer
+1 for FernandaI propose a vote for Fernanda Pizzorno as a Derby committer.Fernanda worked on the implementation of scrollable updateable result sets and has also submitted patches to fix a number of issues. Fernanda is also currently jumping into converting tests to JUnit.Please vote +1 if you agree Fernanda should be a committer.Vote will run for a week.Thanks,Dan. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
[jira] Commented: (DERBY-1965) NetworkServerControlImpl never closes the socket or streams it opens in setUpSocket.
[ http://issues.apache.org/jira/browse/DERBY-1965?page=comments#action_12443033 ] Daniel John Debrunner commented on DERBY-1965: -- Thanks for the review - I used finally blocks to avoid having to re-write the return statement of the class since the return statement itself accessed the open socket or its streams. Yes there should be comments on the closeSocket method. NetworkServerControlImpl never closes the socket or streams it opens in setUpSocket. Key: DERBY-1965 URL: http://issues.apache.org/jira/browse/DERBY-1965 Project: Derby Issue Type: Improvement Components: Network Server Reporter: Daniel John Debrunner Assigned To: Daniel John Debrunner Priority: Minor Attachments: derby1965_diff.txt Every method that calls setUpSocket should have a call to a new closeSocket() method. -- 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: [VOTE] Fernanda Pizzorno as a Derby committer
+1 Daniel John Debrunner wrote On 10/17/06 10:13,: I propose a vote for Fernanda Pizzorno as a Derby committer. Fernanda worked on the implementation of scrollable updateable result sets and has also submitted patches to fix a number of issues. Fernanda is also currently jumping into converting tests to JUnit. Please vote +1 if you agree Fernanda should be a committer. Vote will run for a week. Thanks, Dan.
Re: Show commands are not orthogonal
I also find it a bit strange that SHOW VIEWS uses the heading TABLE_NAME and not VIEW_NAME. In a way, this is similar to DERBY-1072: http://issues.apache.org/jira/browse/DERBY-1072 bryan
[jira] Commented: (DERBY-801) Allow parallel access to data files.
[
http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12443040 ]
Knut Anders Hatlen commented on DERBY-801:
--
I'm wondering whether we should change the DEBUG_PRINT calls to
ASSERT/THROWASSERT. Falling back to the old implementation on errors is a good
approach in insane mode, but I think the errors should be exposed in sane mode
so we can see them and fix them.
After running the JUnit tests (java junit.textui.TestRunner
org.apache.derbyTesting.functionTests.suites.All) I noticed that derby.log
contained this message (but no tests failed):
DEBUG RAFContainerFactory OUTPUT: Caught exception when setting up
rafContainerConstructor
Allow parallel access to data files.
Key: DERBY-801
URL: http://issues.apache.org/jira/browse/DERBY-801
Project: Derby
Issue Type: Improvement
Components: Performance, Store
Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
Environment: Any
Reporter: Øystein Grøvlen
Assigned To: Anders Morken
Attachments: DERBY-801-v2.patch, DERBY-801-v3.patch,
DERBY-801-v4.patch, NIO-RAFContainer-v1.patch
Derby currently serializes accesses to a data file. For example, the
implementation of RAFContainer.readPage is as follows:
synchronized (this) { // 'this' is a FileContainer, i.e. a file object
fileData.seek(pageOffset); // fileData is a RandomAccessFile
fileData.readFully(pageData, 0, pageSize);
}
I have experiemented with a patch where I have introduced several file
descriptors (RandomAccessFile objects) per RAFContainer. These are
used for reading. The principle is that when all readers are busy, a
readPage request will create a new reader. (There is a maximum number
of readers.) With this patch, throughput was improved by 50% on
linux. For more discussion on this, see
http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
The challenge with the suggested approach is to make a mechanism to
limit the number of open file descpriptors. Mike Matrigali has
suggested to use the existing CacheManager infrastructure for this
purpose. For a discussion on that, see:
http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
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: Doc update didn't make it to web site?
I logged into people.apache.org and it looks to me like the automated doc update last succeeded on September 13 Thanks, Jean! Andrew, have you had a chance to look at this? Any ideas? thanks, bryan
Re: Workaround for running JUnit tests with the GUI runners
Kristian Waagan [EMAIL PROTECTED] writes: Hi Dyre, I think you can create a Jira for this, if you haven't already. The problem is that the GUI runners are using a custom classload to allow for dynamic reloading of the test classes. I'm seeing this message in derby.log when I'm running with (any) TestRunner: DEBUG RAFContainerFactory OUTPUT: Caught exception when setting up rafContainerConstructor The tests don't fail because RAFContainerFactory falls back to the old RAFContainer implementation. The exception seems to be a ClassNotFoundException (cannot find RAFContainer4). Could it also be caused by the custom classloader? -- Knut Anders
[jira] Commented: (DERBY-1967) UNION (ALL) contraint violation problem
[
http://issues.apache.org/jira/browse/DERBY-1967?page=comments#action_12443044 ]
Yip Ng commented on DERBY-1967:
---
derbyall passes.
From what Army described in previous comment, this looks like a regression.
UNION (ALL) contraint violation problem
---
Key: DERBY-1967
URL: http://issues.apache.org/jira/browse/DERBY-1967
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.2.1.6, 10.1.3.1
Environment: derby v10.1.3.1 and v10.2.1.6 on linux (FC5), jdk
1.5.0_06-b05
and jdk 1.6.0-rc-b99.
Reporter: Radu Radutiu
Assigned To: Yip Ng
Attachments: derby1967-trunk-diff01.txt, derby1967-trunk-stat01.txt
The following simple test case gives an error:
create table a (f1 varchar(10));
create table b (f2 varchar(10));
insert into b values('test');
select nullif('x','x') as f0, f1 from a
union all
select nullif('x','x') as f0, nullif('x','x') as f1 from b;
ERROR 23502: Column 'F0' cannot accept a NULL value.
SQLState(23502) vendor code(3)
However the following works ok:
drop table a;
drop table b;
create table a (f1 int);
create table b (f2 int);
insert into b values(1);
select nullif('x','x') as f0, f1 from a
union all
select nullif('x','x') as f0, nullif(1,1) as f1 from b;
The test case is a simplification of a query generated by Hibernate
with the table per class inheritance strategy. Both queries work ok on
MSSQL and PostgreSQL. On Derby only the second query works, the first
one giving a contraint violation.
--
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-1967) UNION (ALL) contraint violation problem
[ http://issues.apache.org/jira/browse/DERBY-1967?page=all ]
Yip Ng updated DERBY-1967:
--
Derby Info: [Patch Available, Regression] (was: [Patch Available])
UNION (ALL) contraint violation problem
---
Key: DERBY-1967
URL: http://issues.apache.org/jira/browse/DERBY-1967
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.2.1.6, 10.1.3.1
Environment: derby v10.1.3.1 and v10.2.1.6 on linux (FC5), jdk
1.5.0_06-b05
and jdk 1.6.0-rc-b99.
Reporter: Radu Radutiu
Assigned To: Yip Ng
Attachments: derby1967-trunk-diff01.txt, derby1967-trunk-stat01.txt
The following simple test case gives an error:
create table a (f1 varchar(10));
create table b (f2 varchar(10));
insert into b values('test');
select nullif('x','x') as f0, f1 from a
union all
select nullif('x','x') as f0, nullif('x','x') as f1 from b;
ERROR 23502: Column 'F0' cannot accept a NULL value.
SQLState(23502) vendor code(3)
However the following works ok:
drop table a;
drop table b;
create table a (f1 int);
create table b (f2 int);
insert into b values(1);
select nullif('x','x') as f0, f1 from a
union all
select nullif('x','x') as f0, nullif(1,1) as f1 from b;
The test case is a simplification of a query generated by Hibernate
with the table per class inheritance strategy. Both queries work ok on
MSSQL and PostgreSQL. On Derby only the second query works, the first
one giving a contraint violation.
--
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-1965) NetworkServerControlImpl never closes the socket or streams it opens in setUpSocket.
[
http://issues.apache.org/jira/browse/DERBY-1965?page=comments#action_12443046 ]
Knut Anders Hatlen commented on DERBY-1965:
---
I'm not sure that's the best use of try/finally. Take this code for example:
try {
setUpSocket();
...
} finally {
closeSocket();
}
If an exception (say, IOException) is raised by setUpSocket(), closeSocket() is
invoked but will probably raise a NullPointerException. Then, the IOException
won't be seen because it is masked by the NullPointerException.
NetworkServerControlImpl never closes the socket or streams it opens in
setUpSocket.
Key: DERBY-1965
URL: http://issues.apache.org/jira/browse/DERBY-1965
Project: Derby
Issue Type: Improvement
Components: Network Server
Reporter: Daniel John Debrunner
Assigned To: Daniel John Debrunner
Priority: Minor
Attachments: derby1965_diff.txt
Every method that calls setUpSocket should have a call to a new
closeSocket() method.
--
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-1968) Derby tools guide: Long line in documentation of ij.dataSource
[ http://issues.apache.org/jira/browse/DERBY-1968?page=all ] Kim Haase reassigned DERBY-1968: Assignee: Kim Haase Derby tools guide: Long line in documentation of ij.dataSource -- Key: DERBY-1968 URL: http://issues.apache.org/jira/browse/DERBY-1968 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.1.6, 10.3.0.0 Environment: PDF files Reporter: Øystein Grøvlen Assigned To: Kim Haase Priority: Trivial In the definition of ij.dataSource in the Tools Guide, a line is wider than the page. (Page 16 in 10.2 documentation) -- 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-1965) NetworkServerControlImpl never closes the socket or streams it opens in setUpSocket.
[ http://issues.apache.org/jira/browse/DERBY-1965?page=comments#action_12443049 ] Daniel John Debrunner commented on DERBY-1965: -- Yep, closeSocket() needs to be more defensive. NetworkServerControlImpl never closes the socket or streams it opens in setUpSocket. Key: DERBY-1965 URL: http://issues.apache.org/jira/browse/DERBY-1965 Project: Derby Issue Type: Improvement Components: Network Server Reporter: Daniel John Debrunner Assigned To: Daniel John Debrunner Priority: Minor Attachments: derby1965_diff.txt Every method that calls setUpSocket should have a call to a new closeSocket() method. -- 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: [VOTE] Fernanda Pizzorno as a Derby committer
+1 Daniel John Debrunner wrote: I propose a vote for Fernanda Pizzorno as a Derby committer. Fernanda worked on the implementation of scrollable updateable result sets and has also submitted patches to fix a number of issues. Fernanda is also currently jumping into converting tests to JUnit. Please vote +1 if you agree Fernanda should be a committer. Vote will run for a week. Thanks, Dan. -- Ole Solberg, Database Technology Group, Sun Microsystems, Trondheim, Norway
Re: [VOTE] Fernanda Pizzorno as a Derby committer
+1 Narayanan Daniel John Debrunner wrote On 10/17/06 19:43,: I propose a vote for Fernanda Pizzorno as a Derby committer. Fernanda worked on the implementation of scrollable updateable result sets and has also submitted patches to fix a number of issues. Fernanda is also currently jumping into converting tests to JUnit. Please vote +1 if you agree Fernanda should be a committer. Vote will run for a week. Thanks, Dan.
[jira] Commented: (DERBY-1968) Derby tools guide: Long line in documentation of ij.dataSource
[ http://issues.apache.org/jira/browse/DERBY-1968?page=comments#action_12443054 ] Kim Haase commented on DERBY-1968: -- This is in the file rtoolsijproprefdatasource.dita. I notice that the codeblock that contains the long line looks strange. I think the text is supposed to be on three different lines, but in the DITA source it is not. codeblockbij.dataSource=idataSourcename/i/b bij.dataSource.databaseName=idatabasename/i/b b[ij.dataSource.createDatabase=create]/b/codeblock This is another case of DERBY-408, where the untagged white space in a codeblock is ignored. However, the source at some point lost the line breaks too. I believe the output is meant to look like this (I won't try to reproduce the italics), with the brackets indicating that the last property is optional: ij.dataSource=dataSourcename ij.dataSource.databaseName=databasename [ij.dataSource.createDatabase=create] For an explanation of the example, would it be enough to say the following? The following example creates a database named sample using an EmbeddedDataSource. Or do you think more is needed? Thanks for any feedback. Derby tools guide: Long line in documentation of ij.dataSource -- Key: DERBY-1968 URL: http://issues.apache.org/jira/browse/DERBY-1968 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.1.6, 10.3.0.0 Environment: PDF files Reporter: Øystein Grøvlen Assigned To: Kim Haase Priority: Trivial In the definition of ij.dataSource in the Tools Guide, a line is wider than the page. (Page 16 in 10.2 documentation) -- 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-1785) junit tests fail with permission access problems when run with j9 jvms
[ http://issues.apache.org/jira/browse/DERBY-1785?page=comments#action_12443055 ] Daniel John Debrunner commented on DERBY-1785: -- Notes on how to run Junit tests standalone with WCTME 5.7 foundation are written up in http://wiki.apache.org/db-derby/JunitVmIssues#head-0916dd3630b0667e49460439fbd041c720d93eaf junit tests fail with permission access problems when run with j9 jvms -- Key: DERBY-1785 URL: http://issues.apache.org/jira/browse/DERBY-1785 Project: Derby Issue Type: Test Components: Test, Regression Test Failure Affects Versions: 10.2.1.6, 10.3.0.0 Environment: using ibm's j9 jvm as available with wssd5.6 or wctme5.7 (jcl:Max or jcl:foundation configuration) Reporter: Myrna van Lunteren Assigned To: Myrna van Lunteren Priority: Minor Fix For: 10.2.2.0, 10.3.0.0 Attachments: DERBY-1785_102_20061007.diff, DERBY-1785_20061007.diff The junit tests have been made to run with security manager. Until now, using the org.apache.derbyTesting.functionTests.harness classes, there was exception logic that stopped the j9 jvms from running with security manager, but that's now changed for the junit tests. For instance, the test store/bootAllTest.junit fails with the following error: There was 1 error: 1) testSettingBootAllPropertyWithHomePropertySet(org.apache.derbyTesting.functionTests.tests.store.BootAllTest)java.security.AccessControlException: Access denied (java.util.PropertyPermission framework read) at java.security.AccessController.checkPermission(AccessController.java:74) at java.lang.SecurityManager.checkPermission(SecurityManager.java:612) at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:366) at java.lang.System.getProperty(System.java:319) at java.lang.System.getProperty(System.java:301) at org.apache.derbyTesting.functionTests.util.TestUtil$1.run(TestUtil.java:177) at java.security.AccessController.doPrivileged(AccessController.java:147) at org.apache.derbyTesting.functionTests.util.TestUtil.getFramework(TestUtil.java:174) at org.apache.derbyTesting.functionTests.util.TestUtil.getDataSourcePrefix(TestUtil.java:391) at org.apache.derbyTesting.functionTests.util.TestUtil.getSimpleDataSource(TestUtil.java:330) at org.apache.derbyTesting.functionTests.util.TestUtil.getDataSource(TestUtil.java:324) at org.apache.derbyTesting.functionTests.util.TestDataSourceFactory.getDataSource(TestDataSourceFactory.java:47) at org.apache.derbyTesting.junit.TestConfiguration.openConnection(TestConfiguration.java:296) at org.apache.derbyTesting.junit.BaseJDBCTestCase.openConnection(BaseJDBCTestCase.java:197) at org.apache.derbyTesting.functionTests.tests.store.BootAllTest.setUp(BootAllTest.java:58) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) -- 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-1968) Derby tools guide: Long line in documentation of ij.dataSource
[ http://issues.apache.org/jira/browse/DERBY-1968?page=comments#action_12443057 ] Laura Stewart commented on DERBY-1968: -- Can both the bold and italic be omitted? I think that the example is clear without them. If the italic is desired, then the varname tag should be used. Derby tools guide: Long line in documentation of ij.dataSource -- Key: DERBY-1968 URL: http://issues.apache.org/jira/browse/DERBY-1968 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.1.6, 10.3.0.0 Environment: PDF files Reporter: Øystein Grøvlen Assigned To: Kim Haase Priority: Trivial In the definition of ij.dataSource in the Tools Guide, a line is wider than the page. (Page 16 in 10.2 documentation) -- 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-1973) Support running JUnit tests directly with a remote server
Support running JUnit tests directly with a remote server - Key: DERBY-1973 URL: http://issues.apache.org/jira/browse/DERBY-1973 Project: Derby Issue Type: Improvement Components: Test Reporter: Daniel John Debrunner Provide configuration support to run tests that currently run with the client driver with a remote server. Ideally this would be through a test decorator and not setting properties on the command line. Also ideally it would be good if the embedded tests did not run so that the top level test run could have a class path that only included derbyclient.jar from the derby jars (ie. no derby.jar and derbynet.jar). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Show commands are not orthogonal
Andrew McIntyre wrote: I also find it a bit strange that SHOW VIEWS uses the heading TABLE_NAME and not VIEW_NAME. These are the names of the columns returned from the ResultSet retrieved from DatabaseMetadata.getTables(), and I believe those column names are mandated by the JDBC spec. And, ij displays them faithfully. :-) We could override the column names in a similar way that we set the column widths but I don't think that is really worthwhile. Probably better to just document that little idiosyncrasy. I have seen many database that show tables and views together in the 'show tables' / 'list tables' command. So maybe we can do something similar and make the ij o/p to show something like: create table atab (i int, j int, k int); create view v_atab as select i,j from atab; TABLE_SCHEM |TABLE_NAME|TYPE (?) APP |ATAB |Table APP |V_ATAB |View My 0.02 -Rajesh
Re: Issues with Forrest/Derby Web site (Was: Re: Proposal - Doc Process Improvements)
Laura Stewart wrote: The instructions on the Derby site say to download forrest (which I did) in the following path: C:\Authoring\Forrest\apache-forrest-0.7 The next step says to use the forrest seed command. Nothing happens, the system doesn't recognize this command. ah! The derby instructions need to be more explicit and say for that first step Install Forrest and configure it according to the Forrest instructions. So I went to the Forrest site. http://forrest.apache.org/docs_0_70/your-project.html#installing Their instructions are somewhat different. They mention setting an environment variable for FORREST_HOME. On Windows, is this a user variable or a system variable? I tried adding it (to both) and rebooted, but when I try the command that they recommend (forrest -projecthelp) I get a message indicating that the path/directory is too long (seems odd to me) The exact message is: C:\Authoring\Forrest\apache-forrest-0.7\binforrest -projecthelp The input line is too long. The filename, directory name, or volume label syntax is incorrect. Apache Forrest. Run 'forrest -projecthelp' to list options The input line is too long. Here's an f7_env.bat file I just created on Windows XP: set JAVA_HOME=C:\IBM\Java142 set FORREST_HOME=c:\apache\apache-forrest-0.7 set PATH=%JAVA_HOME%\bin;%FORREST_HOME%\bin;%PATH% set ANT_OPTS=-Xmx512M I then executed that file in a DOS shell to set the variables: C:\jtaf7_env.bat Incidently, the ANT_OPTS option is specifically for building the derby web site -- if that isn't set, then you'll likely run out of memory when you build the web site. (*Incidently, http://db.apache.org/derby/papers/derby_web.html says to set ANT_OPTS to -mx512M, and that didn't work for me just now on Windows. I did a google search and found info to change that to -Xmx512M . Has anyone else noticed this?) At any rate, after setting up my environment this way, I was able to run 'forrest -projecthelp', 'forrest seed', and 'forrest site' in the derby site directory. Also the impression that I have from the Forrest site is that you download forest to one path but you seed a different path Yes; you install the product in one place (in my case, I installed forrest in c:\apache\apache-forrest-0.7), set FORREST_HOME to point to that location and add FORREST_HOME\bin it to your PATH. Then you run forrest in another location where there is a web site to build. 'forrest seed' creates a new web site. That step is in the derby instructions purely to get developers comfortable with running forrest. 'forrest site' is what you run to actually build the derby web site. Any help on getting this working will be appreciated... keep asking questions! If you have that question, most likely others do too. -jean
Re: Issues with Forrest/Derby Web site (Was: Re: Proposal - Doc Process Improvements)
Jean T. Anderson wrote: ... At any rate, after setting up my environment this way, I was able to run 'forrest -projecthelp', 'forrest seed', and 'forrest site' in the derby site directory. I misspoke; don't run 'forrest seed' in the derby site directory. That will generate a new site that overlays the derby web site -- not what you'd want to do. :-) It's ok to run both 'forrest -projecthelp' and 'forrest site' in the derby site directory. -jean
[jira] Created: (DERBY-1974) Junit tests that require SQL authorization mode should use a different database to the default one.
Junit tests that require SQL authorization mode should use a different database to the default one. --- Key: DERBY-1974 URL: http://issues.apache.org/jira/browse/DERBY-1974 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.3.0.0 Reporter: Daniel John Debrunner Since databases are re-used in the JUnit world having a single database for the two modes does not work. Not sure if there are any tests that need this yet. SQLAuthorizationPropTest actually tests setting the property so it really needs its own database (I think). -- 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: [VOTE] Fernanda Pizzorno as a Derby committer
Daniel John Debrunner wrote: I propose a vote for Fernanda Pizzorno as a Derby committer. +1 Olav
[jira] Created: (DERBY-1975) SQLAuthorizationPropTest cannot be run twice against the same database.
SQLAuthorizationPropTest cannot be run twice against the same database. --- Key: DERBY-1975 URL: http://issues.apache.org/jira/browse/DERBY-1975 Project: Derby Issue Type: Bug Reporter: Daniel John Debrunner Assigned To: Daniel John Debrunner Other JUnit tests are setup to successfully run against existing databases, running this test multiple times results in the second time onwards failing. Test should use its own database and drop it at the end of the run. Should create a test decorator to do this. -- 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-408) Fix formatting of manuals in PDF output
[ http://issues.apache.org/jira/browse/DERBY-408?page=comments#action_12443070 ] Kim Haase commented on DERBY-408: - Here's another problem that occurs in the PDF and monohtml but not the plain HTML. It may well be related to the other problem. If you have two adjacent ph tags with white space between them, the white space is ignored. This happens outside of codeblock elements. For example, the JDBC 4 disclaimer that appears in the 10.2 docs begins as follows: pph id=jdbc4disclaimer note type=attention ph conref=toolsconrefs.dita#prod/productshortname/ph ph conref=toolsconrefs.dita#vers/fullversionnumber/ph includes JDBC 4.0 functionality based on a pre-release of Java SE 6. The conrefs translate to Derby and Version 10.2. What shows up in the PDF is DerbyVersion all run together: Attention: DerbyVersion 10.2 includes JDBC 4.0 functionality based on a pre-release of Java SE 6. Putting both ph tags on the same line doesn't help. It's possible this only happens when the ph tags are inside another ph. Fix formatting of manuals in PDF output --- Key: DERBY-408 URL: http://issues.apache.org/jira/browse/DERBY-408 Project: Derby Issue Type: Bug Components: Documentation Environment: all Reporter: Jeff Levitt Assigned To: Andrew McIntyre Priority: Minor Fix For: 10.3.0.0 Attachments: derby-408.diff 1. The syntax boxes in many of the Derby manuals seem to output with extra End-of-line feeds in the PDF's. Some syntax boxes print one word per line. For example: http://incubator.apache.org/derby/docs/tools/tools-single.html#rtoolsijpropref10135 This might be a bug with the DITA toolkit, because the DITA source files dont have these End-of-line feeds in them. This bug was originally reported in the doc reviews for version 10.1: http://issues.apache.org/jira/browse/DERBY-383 (see Myrna's comments) 2. Based on http://issues.apache.org/jira/browse/DERBY-384 comments to the doc review (see Sunitha's comments), we need to figure out how to et the table numbers to ascend. Currently, they all output as table 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
[jira] Commented: (DERBY-1968) Derby tools guide: Long line in documentation of ij.dataSource
[ http://issues.apache.org/jira/browse/DERBY-1968?page=comments#action_12443074 ] Kim Haase commented on DERBY-1968: -- Yes, that works fine for the lines above -- the varname tags italicize the placeholders. There's a problem in the example below, though, where we want to distinguish the user input from the system output. It turns out that our toolkit doesn't do anything with userinput tags (we'd like it to put the contents in bold font, I think). Should this be yet another bug? Derby tools guide: Long line in documentation of ij.dataSource -- Key: DERBY-1968 URL: http://issues.apache.org/jira/browse/DERBY-1968 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.1.6, 10.3.0.0 Environment: PDF files Reporter: Øystein Grøvlen Assigned To: Kim Haase Priority: Trivial In the definition of ij.dataSource in the Tools Guide, a line is wider than the page. (Page 16 in 10.2 documentation) -- 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: [VOTE] Fernanda Pizzorno as a Derby committer
+1 Daniel John Debrunner wrote: I propose a vote for Fernanda Pizzorno as a Derby committer. Fernanda worked on the implementation of scrollable updateable result sets and has also submitted patches to fix a number of issues. Fernanda is also currently jumping into converting tests to JUnit. Please vote +1 if you agree Fernanda should be a committer. Vote will run for a week. Thanks, Dan.
You may have already won: !!! Regression Search and Destroy Contest !!!
After much discussion and consideration our panel of judges have come to a decision regarding the winners of the v 10.2.1 Regression Search and Destroy Contest (and some really good chocolate). The winners are: First Place: Army for work on DERBY-1681, DERBY-1866, DERBY-1633 and DERBY-1315 Second Place: Yip for work on DERBY-1554 and DERBY-1652 and most effort expended Third Place: Prasenjit for work on DERBY-1633 and DERBY-1777 Will the winners please contact me directly with information on addressing the prize packages. Also let me know if you have preferences on the strength of the bars. The bars are all dark chocolate but come in various strengths like the lighter, dark chocolate (around 50% cacao), med dark chocolate (around 60% cacao) or dark, dark chocolate (around 70% cacao). Kathey Marsden wrote: We now have our panel of judges. Thanks to Stan, Rajesh and John for volunteering. Now all we need is an army of users to try their applications and flush all the bugs out of the product and documentation for 10.2. Please take a look and participate. http://wiki.apache.org/db-derby/RegressionSearchAndDestroy === SNIP ===
Docs: Explain the types of DITA topics used in Derby documentation
The Derby Documentation web page http://db.apache.org/derby/manuals/dita.html mentions that there are several types of topics in Derby documentation, but does not explain what they are or how to choose which type to use when you create new topics. I think that the web page should have a new page off of it called Guidelines and section that includes the following info: Choosing the correct topic type There are three types of topics used in the Derby documentation: concepts, reference, and tasks. Concept topics are overview information that answer the question What is...?. They explain why something is important or behaves the way it does. Concepts provide the background information users must understand before they can complete the tasks successfully. Reference topics provide detailed information about product capabilities for quick reference and for completeness. Reference information provides quick access to facts, but no explanation of concepts or procedures. Examples of reference topics are the syntax for commands, and SQL statements, class descriptions, detailed examples, and troubleshooting information. Task topics answer the question How do I?. Tasks typically include step-by-step instructions. Task topics often list (or link to) prerequisites that need to be completed before the user can perform the task. Tasks also list (or link to) any restrictions on performing the task. -- Laura Stewart
[jira] Created: (DERBY-1976) Add new utility methods to BaseJDBCTestCase to make conversion of ij tests to JUnit easier.
Add new utility methods to BaseJDBCTestCase to make conversion of ij tests to JUnit easier. --- Key: DERBY-1976 URL: http://issues.apache.org/jira/browse/DERBY-1976 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.3.0.0 Reporter: A B Priority: Minor As part of my work for DERBY-1758 I'm trying to convert the SQL test lang/xml_general.sql into a JUnit test. In doing so I've found that there are several methods which would make such a conversion easier (and more applicable across different frameworks). In particular the methods I've found useful (and for which I plan to post a patch) are: -- assertSQLState(): This method already exists, but I'd like to expand it so that if the top-level exception doesn't have the target SQLSTATE, the method will look at nested exceptions (if any) and try to determine if any of them match the target SQLSTATE. This added functionality is useful in cases where we have a generic top-level SQLException that in turn has a more specific (and probably more meaningful) nested exception that is really what we want to test. For example, master/xml_general.out has the following lines: ij -- XML cannot be imported or exported. These should all fail. CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE ( null, 'T1', 'xmlexport.del', null, null, null); ERROR 38000: The exception 'java.sql.SQLException: XML values are not allowed in top-level result sets; try using XMLSERIALIZE.' was thrown while evaluating an expression. ERROR 42Z71: XML values are not allowed in top-level result sets; try using XMLSERIALIZE. Since both 38000 and 42Z71 show up in the master file we're effectively checking both of them. With JUnit we could check both by doing something like: assertSQLState(38000, se); assertSQLState(42Z71, se.getNextException()); but that doesn't appear to work for client/server configurations because we don't actually get chained exceptions in client/server; we just get a single exception whose content is the concatenation of the top-level exception's message with the nested exception's message. That said, if we extend assertSQLSTATE() to check nested exceptions and make that check account for the different treatment of nested exceptions in client vs embedded vs jcc, then we can check both SQLSTATEs by making two calls with the same SQLException, namely: assertSQLSTATE(38000, se); assertSQLSTATE(42Z71, se); Or if we don't care about 38000 but are really just interested in 42Z71, then we just make the single call for the latter and ignore the former. Either way the call to assertSQLState() should be enhanced such that it can handle nested exceptions for all frameworks/configurations. -- assertCompileError(): Again, this method already exists. But I'd like to extend it so that if the call to prepareStatement(query) succeeds, the method goes on to call execute() on the prepared statement. The reason for this is that JCC defers preparation until execution time. Thus if we expect a compile-time error in a test and we run it against JCC, the current method will throw an assertionfailure because JCC didn't actually try to compile the query (and thus didn't throw an error). By adding a call to execute() we force JCC to compile and therefore make it so that the method behaves as expected in all frameworks. -- assertStatementError(): A more generic version of assertCompileError() that doesn't care when the error happens. This method executes the query and processes (reads and discards) all rows in the result set(s) (if any) until it hits an error. If no error is thrown then an assertion failure occurs. This method is useful for checking execution-time errors--especially data-specific ones such a divide-by-zero. For example, assume we have a query that returns 3 rows successfully but is expected to throw an error on fourth row. In embedded mode execution of the query will occur without an error and the first three calls to rs.next() will also succeed. Only when the fourth call to rs.next() is made will the error occur. In JCC, though, the error occurs right away as part of the call to execute(). By having a method that doesn't care *when* the error occurs--it just asserts that the error does in fact occur at some point--we make it easier to check for execution-time errors across all frameworks. -- assertDDLRowCount(): Executes a statement using executeUpdate() and asserts that the resultant row count matches an expected row count. This method is itself just one line: +assertEquals(DDL row count doesn't match., +expectedRC, st.executeUpdate(query)); but by putting it in a common place we avoid having to re-type (or copy-paste) the assertion failure
[jira] Updated: (DERBY-1976) Add new utility methods to BaseJDBCTestCase to make conversion of ij tests to JUnit easier.
[ http://issues.apache.org/jira/browse/DERBY-1976?page=all ] A B updated DERBY-1976: --- Attachment: d1976_v1.patch Attaching a patch, d1976_v1.patch, that adds the methods described in the description for this issue. For more details, please see the code comments. I ran the JUnit suite suites.All against ibm142, jdk142, ibm15, jdk15, and jdk16 on a Windows 2000 machine. The only failure I saw was an intermittent failure in LobLengthTest on jdk15: There was 1 error: 1) testLongLobLengths(org.apache.derbyTesting.functionTests.tests.jdbcapi.LobLengthTest) java.sql.SQL Exception: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ001, SQLERRMC: org.apache.derby.shared.common.sanity.AssertFailure#ASSERT FAILED Container closed while IO operations are in progress. This should not happen.#XJ001.U at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:46) at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:345) at org.apache.derby.client.am.Connection.commit(Connection.java:555) at org.apache.derbyTesting.junit.BaseJDBCTestCase.commit(BaseJDBCTestCase.java:159) at org.apache.derbyTesting.functionTests.tests.jdbcapi.LobLengthTest.tearDown(LobLengthTest.java:87) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ001, SQLERRMC: org.apache.derby.shared.common.sanity.AssertFailure#ASSERT FAILED Container closed while IO operations are in progress. This should not happen.#XJ001.U at org.apache.derby.client.am.Connection.completeSqlca(Connection.java:1920) at org.apache.derby.client.net.NetConnectionReply.parseRDBCMMreply(NetConnectionReply.java:215) at org.apache.derby.client.net.NetConnectionReply.readLocalCommit(NetConnectionReply.java:147) at org.apache.derby.client.net.ConnectionReply.readLocalCommit(ConnectionReply.java:43) at org.apache.derby.client.net.NetConnection.readLocalCommit_(NetConnection.java:1574) at org.apache.derby.client.am.Connection.readCommit(Connection.java:639) at org.apache.derby.client.am.Connection.flowCommit(Connection.java:588) at org.apache.derby.client.am.Connection.commit(Connection.java:551) ... 33 more This error occurred once as part of suites.All but did not occur when I ran the test separately and also did not occur when I re-ran the suite a second time. So I don't know if this is specific to jdk15 or not-- but in any event, I don't think this is related to my changes. Review comments/feedback/commit would be much appreciated... Add new utility methods to BaseJDBCTestCase to make conversion of ij tests to JUnit easier. --- Key: DERBY-1976 URL: http://issues.apache.org/jira/browse/DERBY-1976 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.3.0.0 Reporter: A B Priority: Minor Attachments: d1976_v1.patch As part of my work for DERBY-1758 I'm trying to convert the SQL test lang/xml_general.sql into a JUnit test. In doing so I've found that there are several methods which would make such a conversion easier (and more applicable across different frameworks). In particular the methods I've found useful (and for which I plan to post a patch) are: -- assertSQLState(): This method already exists, but I'd like to expand it so that if the top-level exception doesn't have the target SQLSTATE, the method will look at nested exceptions (if any) and try to determine if any of them match the target SQLSTATE. This added functionality is useful in cases where we have a generic top-level SQLException that in turn has a more specific (and probably more meaningful) nested exception that is really what we want to test. For example, master/xml_general.out has the following lines: ij -- XML cannot be imported or exported. These should all fail. CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE ( null, 'T1', 'xmlexport.del', null, null, null); ERROR 38000: The exception
[jira] Updated: (DERBY-1976) Add new utility methods to BaseJDBCTestCase to make conversion of ij tests to JUnit easier.
[ http://issues.apache.org/jira/browse/DERBY-1976?page=all ] A B updated DERBY-1976: --- Assignee: A B Derby Info: [Patch Available] Add new utility methods to BaseJDBCTestCase to make conversion of ij tests to JUnit easier. --- Key: DERBY-1976 URL: http://issues.apache.org/jira/browse/DERBY-1976 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.3.0.0 Reporter: A B Assigned To: A B Priority: Minor Attachments: d1976_v1.patch As part of my work for DERBY-1758 I'm trying to convert the SQL test lang/xml_general.sql into a JUnit test. In doing so I've found that there are several methods which would make such a conversion easier (and more applicable across different frameworks). In particular the methods I've found useful (and for which I plan to post a patch) are: -- assertSQLState(): This method already exists, but I'd like to expand it so that if the top-level exception doesn't have the target SQLSTATE, the method will look at nested exceptions (if any) and try to determine if any of them match the target SQLSTATE. This added functionality is useful in cases where we have a generic top-level SQLException that in turn has a more specific (and probably more meaningful) nested exception that is really what we want to test. For example, master/xml_general.out has the following lines: ij -- XML cannot be imported or exported. These should all fail. CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE ( null, 'T1', 'xmlexport.del', null, null, null); ERROR 38000: The exception 'java.sql.SQLException: XML values are not allowed in top-level result sets; try using XMLSERIALIZE.' was thrown while evaluating an expression. ERROR 42Z71: XML values are not allowed in top-level result sets; try using XMLSERIALIZE. Since both 38000 and 42Z71 show up in the master file we're effectively checking both of them. With JUnit we could check both by doing something like: assertSQLState(38000, se); assertSQLState(42Z71, se.getNextException()); but that doesn't appear to work for client/server configurations because we don't actually get chained exceptions in client/server; we just get a single exception whose content is the concatenation of the top-level exception's message with the nested exception's message. That said, if we extend assertSQLSTATE() to check nested exceptions and make that check account for the different treatment of nested exceptions in client vs embedded vs jcc, then we can check both SQLSTATEs by making two calls with the same SQLException, namely: assertSQLSTATE(38000, se); assertSQLSTATE(42Z71, se); Or if we don't care about 38000 but are really just interested in 42Z71, then we just make the single call for the latter and ignore the former. Either way the call to assertSQLState() should be enhanced such that it can handle nested exceptions for all frameworks/configurations. -- assertCompileError(): Again, this method already exists. But I'd like to extend it so that if the call to prepareStatement(query) succeeds, the method goes on to call execute() on the prepared statement. The reason for this is that JCC defers preparation until execution time. Thus if we expect a compile-time error in a test and we run it against JCC, the current method will throw an assertionfailure because JCC didn't actually try to compile the query (and thus didn't throw an error). By adding a call to execute() we force JCC to compile and therefore make it so that the method behaves as expected in all frameworks. -- assertStatementError(): A more generic version of assertCompileError() that doesn't care when the error happens. This method executes the query and processes (reads and discards) all rows in the result set(s) (if any) until it hits an error. If no error is thrown then an assertion failure occurs. This method is useful for checking execution-time errors--especially data-specific ones such a divide-by-zero. For example, assume we have a query that returns 3 rows successfully but is expected to throw an error on fourth row. In embedded mode execution of the query will occur without an error and the first three calls to rs.next() will also succeed. Only when the fourth call to rs.next() is made will the error occur. In JCC, though, the error occurs right away as part of the call to execute(). By having a method that doesn't care *when* the error occurs--it just asserts that the error does in fact occur at some point--we make it easier to check for execution-time errors across all frameworks. -- assertDDLRowCount(): Executes a statement using executeUpdate() and asserts that the resultant
Re: [jira] Created: (DERBY-1976) Add new utility methods to BaseJDBCTestCase to make conversion of ij tests to JUnit easier.
A B (JIRA) wrote: As part of my work for DERBY-1758 I'm trying to convert the SQL test lang/xml_general.sql into a JUnit test. [snip set of good utility methods] Just to note, .sql tests can be converted with very little effort by using the ScriptTestCase utility class, see LangScripts for an example of its use in language tests. If the SQL script has multiple masters or needs its output sed'ed then a pure Junit test is probably better. I'm planning to write this up on the wiki soon. Dan.
Re: [jira] Created: (DERBY-1976) Add new utility methods to BaseJDBCTestCase to make conversion of ij tests to JUnit easier.
Daniel John Debrunner wrote: Just to note, .sql tests can be converted with very little effort by using the ScriptTestCase utility class, see LangScripts for an example of its use in language tests. I did notice that class and I actually started by trying to use it. But I then ran into the thing you just noted, namely: If the SQL script has multiple masters or needs its output sed'ed then a pure Junit test is probably better. Both of these are true for lang/xml_general.sql. I was originally hoping to get just sneak by with the ScripTestCase class, but alas, I ran into the sed barrier. I figured it'd be best to go for pure JUnit than to try to work sed into JUnit somehow... Thanks for quick feedback! Army
[jira] Commented: (DERBY-1976) Add new utility methods to BaseJDBCTestCase to make conversion of ij tests to JUnit easier.
[ http://issues.apache.org/jira/browse/DERBY-1976?page=comments#action_12443111 ] Daniel John Debrunner commented on DERBY-1976: -- Some of these methods might be better in org.apache.derbyTesting.junit.JDBC E.g. expanding assertDrainResultSet to alos take a row count would provide better testing than a simple row count. assertDDLRowCount() would be better named as assertUpdateCount() since that's what I think it is testing. Add new utility methods to BaseJDBCTestCase to make conversion of ij tests to JUnit easier. --- Key: DERBY-1976 URL: http://issues.apache.org/jira/browse/DERBY-1976 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.3.0.0 Reporter: A B Assigned To: A B Priority: Minor Attachments: d1976_v1.patch As part of my work for DERBY-1758 I'm trying to convert the SQL test lang/xml_general.sql into a JUnit test. In doing so I've found that there are several methods which would make such a conversion easier (and more applicable across different frameworks). In particular the methods I've found useful (and for which I plan to post a patch) are: -- assertSQLState(): This method already exists, but I'd like to expand it so that if the top-level exception doesn't have the target SQLSTATE, the method will look at nested exceptions (if any) and try to determine if any of them match the target SQLSTATE. This added functionality is useful in cases where we have a generic top-level SQLException that in turn has a more specific (and probably more meaningful) nested exception that is really what we want to test. For example, master/xml_general.out has the following lines: ij -- XML cannot be imported or exported. These should all fail. CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE ( null, 'T1', 'xmlexport.del', null, null, null); ERROR 38000: The exception 'java.sql.SQLException: XML values are not allowed in top-level result sets; try using XMLSERIALIZE.' was thrown while evaluating an expression. ERROR 42Z71: XML values are not allowed in top-level result sets; try using XMLSERIALIZE. Since both 38000 and 42Z71 show up in the master file we're effectively checking both of them. With JUnit we could check both by doing something like: assertSQLState(38000, se); assertSQLState(42Z71, se.getNextException()); but that doesn't appear to work for client/server configurations because we don't actually get chained exceptions in client/server; we just get a single exception whose content is the concatenation of the top-level exception's message with the nested exception's message. That said, if we extend assertSQLSTATE() to check nested exceptions and make that check account for the different treatment of nested exceptions in client vs embedded vs jcc, then we can check both SQLSTATEs by making two calls with the same SQLException, namely: assertSQLSTATE(38000, se); assertSQLSTATE(42Z71, se); Or if we don't care about 38000 but are really just interested in 42Z71, then we just make the single call for the latter and ignore the former. Either way the call to assertSQLState() should be enhanced such that it can handle nested exceptions for all frameworks/configurations. -- assertCompileError(): Again, this method already exists. But I'd like to extend it so that if the call to prepareStatement(query) succeeds, the method goes on to call execute() on the prepared statement. The reason for this is that JCC defers preparation until execution time. Thus if we expect a compile-time error in a test and we run it against JCC, the current method will throw an assertionfailure because JCC didn't actually try to compile the query (and thus didn't throw an error). By adding a call to execute() we force JCC to compile and therefore make it so that the method behaves as expected in all frameworks. -- assertStatementError(): A more generic version of assertCompileError() that doesn't care when the error happens. This method executes the query and processes (reads and discards) all rows in the result set(s) (if any) until it hits an error. If no error is thrown then an assertion failure occurs. This method is useful for checking execution-time errors--especially data-specific ones such a divide-by-zero. For example, assume we have a query that returns 3 rows successfully but is expected to throw an error on fourth row. In embedded mode execution of the query will occur without an error and the first three calls to rs.next() will also succeed. Only when the fourth call to rs.next() is made will the error occur. In JCC, though, the error occurs right away as part of the
[jira] Commented: (DERBY-1967) UNION (ALL) contraint violation problem
[
http://issues.apache.org/jira/browse/DERBY-1967?page=comments#action_12443116 ]
A B commented on DERBY-1967:
Thanks for the quick turn-around on this, Yip.
Your description of the problem sounds correct to me and the changes themselves
match what you say. They also line up with DERBY-7 as the code in question was
added as part of that issue.
I confirmed that the patch applies cleanly to trunk and that the new test case
fails without your changes and passes with it. The code comments also indicate
why the change was necessary, which is great.
It's a pretty small change, it makes sense to me, and derbayll passed. So I
vote +1 to commit...
UNION (ALL) contraint violation problem
---
Key: DERBY-1967
URL: http://issues.apache.org/jira/browse/DERBY-1967
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.2.1.6, 10.1.3.1
Environment: derby v10.1.3.1 and v10.2.1.6 on linux (FC5), jdk
1.5.0_06-b05
and jdk 1.6.0-rc-b99.
Reporter: Radu Radutiu
Assigned To: Yip Ng
Attachments: derby1967-trunk-diff01.txt, derby1967-trunk-stat01.txt
The following simple test case gives an error:
create table a (f1 varchar(10));
create table b (f2 varchar(10));
insert into b values('test');
select nullif('x','x') as f0, f1 from a
union all
select nullif('x','x') as f0, nullif('x','x') as f1 from b;
ERROR 23502: Column 'F0' cannot accept a NULL value.
SQLState(23502) vendor code(3)
However the following works ok:
drop table a;
drop table b;
create table a (f1 int);
create table b (f2 int);
insert into b values(1);
select nullif('x','x') as f0, f1 from a
union all
select nullif('x','x') as f0, nullif(1,1) as f1 from b;
The test case is a simplification of a query generated by Hibernate
with the table per class inheritance strategy. Both queries work ok on
MSSQL and PostgreSQL. On Derby only the second query works, the first
one giving a contraint violation.
--
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: [VOTE] Fernanda Pizzorno as a Derby committer
Daniel John Debrunner wrote: I propose a vote for Fernanda Pizzorno as a Derby committer. +1 -Rajesh
