[jira] Updated: (DERBY-1895) Convert jdbcapi/blobclob4BLOB.java to Junit
[ http://issues.apache.org/jira/browse/DERBY-1895?page=all ] Fernanda Pizzorno updated DERBY-1895: - Derby Info: [Patch Available] Convert jdbcapi/blobclob4BLOB.java to Junit --- Key: DERBY-1895 URL: http://issues.apache.org/jira/browse/DERBY-1895 Project: Derby Issue Type: Sub-task Reporter: Fernanda Pizzorno Assigned To: Fernanda Pizzorno Attachments: derby-1895.diff, derby-1895.html, derby-1895.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
[jira] Commented: (DERBY-1895) Convert jdbcapi/blobclob4BLOB.java to Junit
[
http://issues.apache.org/jira/browse/DERBY-1895?page=comments#action_12442521 ]
Knut Anders Hatlen commented on DERBY-1895:
---
Hi Fernanda. Thank you for rewriting the test! I had a quick look at your patch
and the description of it. A couple of question/comments:
- Some of the test cases (testSetClobToIntColumn, testSetClobToIntColumn,
testSetClobToIntColumn) have comments saying need to run prepareCLOBMAIN
first, but there is no such method.
- I'm not sure I understand what testClobFinalizer and testBlobFinalizer test.
Is their only purpose to force the finalizers to run? If so, would it make
sense to add System.runFinalization() after System.gc().
- The testPosition* cases use random start position and length. If these tests
fail, it could be hard to reproduce because we don't know the actual values.
Could the start position and length be part of the error message? (I saw the
println() statements, but they only print the information when the verbose flag
is true.)
- runPositionStringTest() has a workaround for DERBY-1917. When the test has
been committed, a comment should be added to 1917 that the test should be
cleaned up when it has been fixed.
- The suite() method adds each test case manually. I think it would be better
to use the built-in JUnit functionality for adding all test* methods and only
add those test cases that don't run under DerbyNet manually. That would make it
easier to add more test cases later, and it would be more consistent with the
other JUnit tests.
- Minor nit: many calls to assertTrue(XXX, false) would be easier to read if
written as fail(XXX).
- I found many constructions similar to this:
+try {
+clob.length();
+if (usingEmbedded()) {
+assertTrue(FAIL - should not be able to access large log +
+after commit, false);
+}
+} catch (SQLException e) {
+checkException(BLOB_ACCESSED_AFTER_COMMIT, e);
+}
If I understand these constructions correctly, they expect embedded to fail
with a given SQLState, but the network client and JCC should succeed. But under
DerbyNet and DerbyNetClient, these test cases will succeed both when the call
succeeds and when the call fails with the given SQLState. Is this how it was
intended?
Convert jdbcapi/blobclob4BLOB.java to Junit
---
Key: DERBY-1895
URL: http://issues.apache.org/jira/browse/DERBY-1895
Project: Derby
Issue Type: Sub-task
Reporter: Fernanda Pizzorno
Assigned To: Fernanda Pizzorno
Attachments: derby-1895.diff, derby-1895.html, derby-1895.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
[jira] Updated: (DERBY-1893) Convert largedata/lobLengthTests.java to junit
[ http://issues.apache.org/jira/browse/DERBY-1893?page=all ] Øystein Grøvlen updated DERBY-1893: --- Attachment: derby1893_v2.diff derby1893_v2.stat I have attached new versions of the patch and the stat output, derby1893_v2*. The patch is regenerated at the current head of trunk. In addition, I have removed the master file for the old test as pointed out by Fernanda. Convert largedata/lobLengthTests.java to junit -- Key: DERBY-1893 URL: http://issues.apache.org/jira/browse/DERBY-1893 Project: Derby Issue Type: Sub-task Components: Test Reporter: Øystein Grøvlen Assigned To: Øystein Grøvlen Priority: Trivial Attachments: derby1893.diff, derby1893.stat, derby1893_v2.diff, derby1893_v2.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
[jira] Created: (DERBY-1961) Investigate resource usage for different types of load on an in-memory database
Investigate resource usage for different types of load on an in-memory database --- Key: DERBY-1961 URL: http://issues.apache.org/jira/browse/DERBY-1961 Project: Derby Issue Type: Task Components: Performance Reporter: Knut Anders Hatlen Priority: Minor Investigate how much resources Derby uses and in which parts of the code they are used on an in-memory database. Find numbers for different kinds of load: single-record update and select operations, and join operations. Example of resource usage that could be measured: CPU, wall-clock time, system calls, context switches, monitor contention, object allocations, garbage collection, I/O. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (DERBY-1883) I18N tests fail on Linux/JVM 1.4.2 when derbyclient.jar is the first element of the classpath
[ http://issues.apache.org/jira/browse/DERBY-1883?page=all ] Knut Anders Hatlen reopened DERBY-1883: --- I18N tests fail on Linux/JVM 1.4.2 when derbyclient.jar is the first element of the classpath - Key: DERBY-1883 URL: http://issues.apache.org/jira/browse/DERBY-1883 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.2.1.6, 10.3.0.0 Environment: Linux, Sun J2SE 1.4.2, CLASSPATH=derbyclient.jar: Reporter: Knut Anders Hatlen Assigned To: Knut Anders Hatlen Priority: Minor Fix For: 10.3.0.0 Attachments: 1883.diff i18n/urlLocale.sql, i18n/messageLocale.sql and i18n/iepnegativetests_ES.sql fail on Linux when running Sun J2SE 1.4.2 and derbyclient.jar is the first element of the classpath. See http://www.multinet.no/~solberg/public/Apache/10.2.1.3_RC/jvm1.4/testlog/linN-1/441574-derbyall_diff.txt. The problem is not seen on Solaris or FreeBSD, or when running with 1.5/1.6 JVM. When derbyclient.jar is moved to a position after derby.jar in the classpath, the tests run successfully. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1961) Investigate resource usage for different types of load on an in-memory database
[ http://issues.apache.org/jira/browse/DERBY-1961?page=all ] Knut Anders Hatlen updated DERBY-1961: -- Attachment: TestClient.java Uploaded a test client which can be used to investigate the resource usage for three different loads: - single-record select operations: select one row from a table of 10 rows (each row is 100 bytes) - single-record update operations: update one row in a table of 10 rows (same table as above) - join of a table of 1 rows with a table of 1000 rows - 1000 rows in each result All operations use primary keys. The joins work on tables which have the same schema as the tables in the Wisconsin test in Derby's regression test suite. The client uses the Wisconsin test code to fill the tables, and therefore derbyTesting.jar must be in the classpath when the test database is initialized. Run java TestClient -h to learn how to run the test clients. Investigate resource usage for different types of load on an in-memory database --- Key: DERBY-1961 URL: http://issues.apache.org/jira/browse/DERBY-1961 Project: Derby Issue Type: Task Components: Performance Reporter: Knut Anders Hatlen Priority: Minor Attachments: TestClient.java Investigate how much resources Derby uses and in which parts of the code they are used on an in-memory database. Find numbers for different kinds of load: single-record update and select operations, and join operations. Example of resource usage that could be measured: CPU, wall-clock time, system calls, context switches, monitor contention, object allocations, garbage collection, I/O. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1962) Convert jdbcapi/resultsetJdbc30.java to junit
Convert jdbcapi/resultsetJdbc30.java to junit - Key: DERBY-1962 URL: http://issues.apache.org/jira/browse/DERBY-1962 Project: Derby Issue Type: Sub-task Reporter: Fernanda Pizzorno Assigned To: Fernanda Pizzorno -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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_12442561 ] Tomohito Nakayama commented on DERBY-187: - I found that tomcat5.exe in Tomcat package is binary of procrun. I could register DerbyNetServer as Windows service using next command. tomcat5.exe //IS//Derby --DisplayName=derby --StartMode=jvm --StopMode=exe --StartClass=org.apache.derby.drda.NetworkServerControl --StartParams=start --Classpath=C:\work\20061015\db-derby-10.2.1.6-bin\lib\derby.jar;C:\work\20061015\db-derby-10.2.1.6-bin\lib\derbynet.jar --Jvm=C:\j2sdk1.4.2_05\jre\bin\server\jvm.dll --StopClass=org.apache.derby.drda.NetworkServerControl --StopParams=shutdown 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
[jira] Commented: (DERBY-1961) Investigate resource usage for different types of load on an in-memory database
[ http://issues.apache.org/jira/browse/DERBY-1961?page=comments#action_12442566 ] Knut Anders Hatlen commented on DERBY-1961: --- Created wiki page where results could be posted: http://wiki.apache.org/db-derby/Derby1961ResourceUsage Investigate resource usage for different types of load on an in-memory database --- Key: DERBY-1961 URL: http://issues.apache.org/jira/browse/DERBY-1961 Project: Derby Issue Type: Task Components: Performance Reporter: Knut Anders Hatlen Priority: Minor Attachments: TestClient.java Investigate how much resources Derby uses and in which parts of the code they are used on an in-memory database. Find numbers for different kinds of load: single-record update and select operations, and join operations. Example of resource usage that could be measured: CPU, wall-clock time, system calls, context switches, monitor contention, object allocations, garbage collection, I/O. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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] Making progess faster towards a pure Junit world
Kristian Waagan [EMAIL PROTECTED] writes: Daniel John Debrunner wrote: I'd like to make progress faster towards a pure JUnit set of tests for Derby but I believe the fact we need to setup the tests and the JUnit utility classes to run under the harness slows down progress as well as adding complications. An example of how it slows down is that any change to a test or JUnit utility class requires that the contributor runs the tests multiple ways to ensure no regressions. Assuming we had a top-level JUnit suite that ran all the Junit tests successfully (with the same configuration coverage as they are run today in derbyall) then could we switch to a dual testing environment until all the tests were converted to JUnit? This would include removing all the JUnit tests from the old harness suite files. That is if one wanted to run all the tests one would have to run: derbyall with the old harness suites.All using JUnit test runners directly. Is this an issue for people? Hi, For me this is not an issue. I might even be able to run the two in parallel by changing the port number for the JUnit run. I'm happy to see that there is activity on converting tests to JUnit. We still have a long way to go though, so keep up the good work! (BTW: I have some problems with the security manager, and if people have any ideas, I'd like to hear them; http://issues.apache.org/jira/browse/DERBY-1001) 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? -- dt
[jira] Commented: (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=comments#action_12442589 ] Tomohito Nakayama commented on DERBY-1535: -- I will resume this issue as improving room left in DERBY-1559. http://issues.apache.org/jira/browse/DERBY-1559#action_12430023 http://issues.apache.org/jira/browse/DERBY-1559#action_12430034 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, 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
[jira] Resolved: (DERBY-1942) There exists difference between behavior of setNull(Types.TIME) and setTiime(null).
[ http://issues.apache.org/jira/browse/DERBY-1942?page=all ] Tomohito Nakayama resolved DERBY-1942. -- Resolution: Fixed There exists difference between behavior of setNull(Types.TIME) and setTiime(null). Key: DERBY-1942 URL: http://issues.apache.org/jira/browse/DERBY-1942 Project: Derby Issue Type: Bug Components: JDBC Reporter: Tomohito Nakayama Assigned To: Tomohito Nakayama Attachments: DERBY-1942.patch The result of setNull(java.sql.Types.TIME) for TIMESTAMP typed variable is regarded as error. However, the result of setTime(null) for TIMESTAMP typed variable is not regarded as error . see http://issues.apache.org/jira/browse/DERBY-1610#action_12436554 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1962) Convert jdbcapi/resultsetJdbc30.java to junit
[ http://issues.apache.org/jira/browse/DERBY-1962?page=all ] Attachment: derby-1962.diff derby-1962.stat Convert jdbcapi/resultsetJdbc30.java to junit - Key: DERBY-1962 URL: http://issues.apache.org/jira/browse/DERBY-1962 Project: Derby Issue Type: Sub-task 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
[jira] Resolved: (DERBY-1893) Convert largedata/lobLengthTests.java to junit
[ http://issues.apache.org/jira/browse/DERBY-1893?page=all ] Bernt M. Johnsen resolved DERBY-1893. - Resolution: Fixed Derby Info: (was: [Patch Available]) Committed revision 464504. Convert largedata/lobLengthTests.java to junit -- Key: DERBY-1893 URL: http://issues.apache.org/jira/browse/DERBY-1893 Project: Derby Issue Type: Sub-task Components: Test Reporter: Øystein Grøvlen Assigned To: Øystein Grøvlen Priority: Trivial Attachments: derby1893.diff, derby1893.stat, derby1893_v2.diff, derby1893_v2.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
[jira] Commented: (DERBY-737) SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they do not exist
[ http://issues.apache.org/jira/browse/DERBY-737?page=comments#action_12442614 ] Mamta A. Satoor commented on DERBY-737: --- Thanks for taking the time out to review the patch, Bryan. Yes, the patch is ready for commit unless someone else is reviewing it too. Thanks again. SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they do not exist - Key: DERBY-737 URL: http://issues.apache.org/jira/browse/DERBY-737 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.1.3.1, 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.2.1.6, 10.0.2.2 Reporter: Kathey Marsden Assigned To: Mamta A. Satoor Priority: Minor Attachments: DERBY737_v1_diff_SYSCS_COMPRESS_TABLE.txt, DERBY737_v1_stat_SYSCS_COMPRESS_TABLE.txt There must be an entry in the SYSSTATISTICS table in order for the cardinality statistics in SYSSTATISTICS to be created with SYSCS_UTIL.SYSCS_COMPRESS_TABLE SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they don't exist. The only way to create them if the index was created on an empty table, seems to be to drop and recreate the index after the table has been loaded. The documentation will also need updating if this change is made. http://db.apache.org/derby/docs/10.1/tuning/ctunstats57373.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
[jira] Updated: (DERBY-1962) Convert jdbcapi/resultsetJdbc30.java to junit
[ http://issues.apache.org/jira/browse/DERBY-1962?page=all ] Fernanda Pizzorno updated DERBY-1962: - Component/s: Test Derby Info: [Patch Available] The attached patch (derby-1962.diff) converts the test jdbcapi/resultsetJdbc30.java to Junit. A summary of what it tested by this test can be found at: http://wiki.apache.org/db-derby/ResultSetJDBC30TestCoverage. I have successfully run jdbcapi with this patch. Can someone please review it? 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
[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_12442621 ] Tomohito Nakayama commented on DERBY-187: - Seeing result of sc command, I came to think that some of program should be included in derby to make it possible to run NetworkServer as service. Considering license issue, procrun may be appropriate for that because it also is under apache software license ... ... Is it impossible to include tomcat5.exe as derby.exe ? 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
Policy change on the 10.2 branch
Now that 10.2.1 has gone GA, we can relax the policy governing the 10.2 branch. Please feel free to port bug fixes to the 10.2 branch. I think we should continue to avoid porting new features to 10.2, however. I would like to aim for a quick vetting cycle for the next release in the 10.2 lineage. That would be 10.2.2, the release which exposes compiled versions of our JDBC4 drivers soon after Java SE 6 goes GA in early December. Regards, -Rick
CLA and ICLA policy clarified
Last week at ApacheCon, I attended most of Cliff Schmidt's sessions on intellectual property issues. Cliff is the ASF's vice president for legal affairs. Cliff clarified that ICLAs are only needed for committers. Similarly, a company's CLA only needs to cover its committers. According to Cliff, we don't need ICLA/CLA coverage for contributors who aren't committers. It seems to me that Derby's policy is stricter than this. As I recall, we require ICLA/CLA coverage for all contributors, regardless of whether they are committers. Why is Derby's policy stricter than general ASF policy? Thanks, -Rick
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (14 issues) Subscriber: derby-dev Key Summary DERBY-1962 Convert jdbcapi/resultsetJdbc30.java to junit http://issues.apache.org/jira/browse/DERBY-1962 DERBY-737 SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they do not exist http://issues.apache.org/jira/browse/DERBY-737 DERBY-1895 Convert jdbcapi/blobclob4BLOB.java to Junit http://issues.apache.org/jira/browse/DERBY-1895 DERBY-1953 Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional http://issues.apache.org/jira/browse/DERBY-1953 DERBY-1948 10.2 'Working with Derby' manual errors. http://issues.apache.org/jira/browse/DERBY-1948 DERBY-1839 Doc Review Updates - Ref Manual http://issues.apache.org/jira/browse/DERBY-1839 DERBY-1954 Update sysinfo output documentation in Tools and Utilities Guide http://issues.apache.org/jira/browse/DERBY-1954 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
Re: CLA and ICLA policy clarified
Rick Hillegas wrote: Last week at ApacheCon, I attended most of Cliff Schmidt's sessions on intellectual property issues. Cliff is the ASF's vice president for legal affairs. Cliff clarified that ICLAs are only needed for committers. Similarly, a company's CLA only needs to cover its committers. According to Cliff, we don't need ICLA/CLA coverage for contributors who aren't committers. It seems to me that Derby's policy is stricter than this. As I recall, we require ICLA/CLA coverage for all contributors, regardless of whether they are committers. Why is Derby's policy stricter than general ASF policy? I knew I was going to regret flying out early and missing those final legal sessions. An FAQ on ICLAs is at http://db.apache.org/derby/faq.html#derby_icla . http://www.apache.org/licenses/ says in the section titled Contributor License Agreements: The ASF desires that all contributors of ideas, code, or documentation to the Apache projects complete, sign, and submit (via snailmail or fax) an Individual Contributor License Agreement (CLA) [PDF form]. The purpose of this agreement is to clearly define the terms under which intellectual property has been contributed to the ASF and thereby allow us to defend the project should there be a legal dispute regarding the software at some future time. A signed CLA is required to be on file before an individual is given commit rights to an ASF project. So, the stated policy is the ICLA is *desired* for contributors and *required* for committers. Apache projects decide what contribution is big enough to require an ICLA, and that bar varies quite a bit from one project to the next. I seem to recall that small Derby contributions have not been held up by lack of an ICLA. I'll look for an example of that if it's interesting. -jean
Regression Test Report - 464218 - Sun DBTG
[Auto-generated mail] ** 464218/2006-10-15 18:00:07 MEST ** Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 0688688 0 106.75% lin NA NA NANA sol 0688688 097.51% solN+1 0688688 0 108.10% sparc 1688687 0 161.14% win Details in http://www.multinet.no/~solberg/public/Apache/Daily/jvm1.6/Limited/testSummary-464218.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Daily/Failures/jvm1.6/464218.html *Jvm: 1.5* 0676676 2 105.48% lin NA NA NANA sol 0676676 297.17% solN+1 0676676 2 107.45% sparc 1676675 2 170.51% win Details in http://www.multinet.no/~solberg/public/Apache/Daily/jvm1.5/Limited/testSummary-464218.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Daily/Failures/jvm1.5/464218.html *Jvm: 1.4* 0670670 4 105.49% lin NA NA NANA sol 0670670 497.93% solN+1 0670670 4 107.03% sparc 1670669 497.07% win Details in http://www.multinet.no/~solberg/public/Apache/Daily/jvm1.4/Limited/testSummary-464218.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Daily/Failures/jvm1.4/464218.html --- Changes in http://www.multinet.no/~solberg/public/Apache/Daily/UpdateInfo/464218.txt ( All results in http://www.multinet.no/~solberg/public/Apache/Daily/index.html )
Re: CLA and ICLA policy clarified
Jean T. Anderson wrote: Rick Hillegas wrote: Last week at ApacheCon, I attended most of Cliff Schmidt's sessions on intellectual property issues. Cliff is the ASF's vice president for legal affairs. Cliff clarified that ICLAs are only needed for committers. Similarly, a company's CLA only needs to cover its committers. According to Cliff, we don't need ICLA/CLA coverage for contributors who aren't committers. It seems to me that Derby's policy is stricter than this. As I recall, we require ICLA/CLA coverage for all contributors, regardless of whether they are committers. Why is Derby's policy stricter than general ASF policy? ... Apache projects decide what contribution is big enough to require an ICLA, and that bar varies quite a bit from one project to the next. I seem to recall that small Derby contributions have not been held up by lack of an ICLA. I'll look for an example of that if it's interesting. From a quick look, I spot several contributors who have not been nagged to file ICLAs, so there are probably more. I don't want to name names here because I don't want them to feel that their contributions were somehow not significant enough to merit being nagged to file an ICLA. We appreciate all contributions and anyone who wants to contribute to Derby (or any other ASF project) should feel free to go ahead and file an ICLA. Also, I don't know that Derby has a policy per se; committers have just noticed when something that looked like a significant contribution didn't have an ICLA. For example, committing the patch for DERBY-587 (JDBC 4.0 support) was held up until the ICLA was recorded. Hindsight is 20/20 and given the JDBC 4 licensing issues that affected the Derby 10.2 release, I'm glad Satheesh raised it as a commit issue: https://issues.apache.org/jira/browse/DERBY-587#action_12356249 . Should Derby have a formal policy? Or is evaluating contributions case by case sufficient? -jean
[jira] Commented: (DERBY-408) Fix formatting of manuals in PDF output
[ http://issues.apache.org/jira/browse/DERBY-408?page=comments#action_12442633 ] Laura Stewart commented on DERBY-408: - I don't believe that the documentation should use tags like bold b to force line breaks. Infact, in most cases there shouldn't be bold tags inside of codeblocks and syntax. Typically uppercase letters are used for the required SQL and lowercase letters for the variables such as index-name. Sometimes varname is used for the variables, which displays the text in italic. This sounds like a DITA - to - XSL-FO problem. 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] Updated: (DERBY-737) SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they do not exist
[ http://issues.apache.org/jira/browse/DERBY-737?page=all ] Bryan Pendleton updated DERBY-737: -- Derby Info: (was: [Patch Available]) Committed the patch to subversion as revision 464551. Mamta, do you think this patch needs to be ported to any prior releases? SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they do not exist - Key: DERBY-737 URL: http://issues.apache.org/jira/browse/DERBY-737 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.1.3.1, 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.2.1.6, 10.0.2.2 Reporter: Kathey Marsden Assigned To: Mamta A. Satoor Priority: Minor Attachments: DERBY737_v1_diff_SYSCS_COMPRESS_TABLE.txt, DERBY737_v1_stat_SYSCS_COMPRESS_TABLE.txt There must be an entry in the SYSSTATISTICS table in order for the cardinality statistics in SYSSTATISTICS to be created with SYSCS_UTIL.SYSCS_COMPRESS_TABLE SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they don't exist. The only way to create them if the index was created on an empty table, seems to be to drop and recreate the index after the table has been loaded. The documentation will also need updating if this change is made. http://db.apache.org/derby/docs/10.1/tuning/ctunstats57373.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
[jira] Commented: (DERBY-1942) There exists difference between behavior of setNull(Types.TIME) and setTiime(null).
[ http://issues.apache.org/jira/browse/DERBY-1942?page=comments#action_12442640 ] Dag H. Wanvik commented on DERBY-1942: -- Should this issue perhaps have the existing application impact and release note needed flags set? It seems you have made something illegal that worked before... There exists difference between behavior of setNull(Types.TIME) and setTiime(null). Key: DERBY-1942 URL: http://issues.apache.org/jira/browse/DERBY-1942 Project: Derby Issue Type: Bug Components: JDBC Reporter: Tomohito Nakayama Assigned To: Tomohito Nakayama Attachments: DERBY-1942.patch The result of setNull(java.sql.Types.TIME) for TIMESTAMP typed variable is regarded as error. However, the result of setTime(null) for TIMESTAMP typed variable is not regarded as error . see http://issues.apache.org/jira/browse/DERBY-1610#action_12436554 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1963) Routine parameter names displayed by dblook are not escaped.
Routine parameter names displayed by dblook are not escaped. Key: DERBY-1963 URL: http://issues.apache.org/jira/browse/DERBY-1963 Project: Derby Issue Type: Bug Components: Tools Reporter: Daniel John Debrunner Priority: Minor Fix For: 10.3.0.0 After using this SQL to create a function with a delimited parameter name CREATE FUNCTION FRED (paramOne INTEGER) RETURNS INTEGER LANGUAGE JAVA PARAMETER STYLE JAVA EXTERNAL NAME 'fred.foo' dblook will output a CREATE FUNCTION statement with the parameter name without quotes: CREATE FUNCTION APP.FRED (paramOne INTEGER) RETURNS INTEGER LANGUAGE JAVA PARAMETER STYLE JAVA READS SQL DATA CALLED ON NULL INPUT EXTERNAL NAME 'fred.foo'; Using the output from dblook to re-create the function will result in a function with a different parameter name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1963) Routine parameter names displayed by dblook are not escaped.
[ http://issues.apache.org/jira/browse/DERBY-1963?page=all ] Daniel John Debrunner updated DERBY-1963: - Affects Version/s: 10.3.0.0 Routine parameter names displayed by dblook are not escaped. Key: DERBY-1963 URL: http://issues.apache.org/jira/browse/DERBY-1963 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.3.0.0 Reporter: Daniel John Debrunner Priority: Minor Fix For: 10.3.0.0 After using this SQL to create a function with a delimited parameter name CREATE FUNCTION FRED (paramOne INTEGER) RETURNS INTEGER LANGUAGE JAVA PARAMETER STYLE JAVA EXTERNAL NAME 'fred.foo' dblook will output a CREATE FUNCTION statement with the parameter name without quotes: CREATE FUNCTION APP.FRED (paramOne INTEGER) RETURNS INTEGER LANGUAGE JAVA PARAMETER STYLE JAVA READS SQL DATA CALLED ON NULL INPUT EXTERNAL NAME 'fred.foo'; Using the output from dblook to re-create the function will result in a function with a different parameter name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-737) SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they do not exist
[ http://issues.apache.org/jira/browse/DERBY-737?page=comments#action_12442641 ] Mamta A. Satoor commented on DERBY-737: --- Bryan, thanks for committing the patch to the trunk. I think it will be useful to port this patch to prior releases because optimizer relies on the statistics information for indexes on a table. As for documentation, I will open another Jira entry for the doc changes. SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they do not exist - Key: DERBY-737 URL: http://issues.apache.org/jira/browse/DERBY-737 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.1.3.1, 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.2.1.6, 10.0.2.2 Reporter: Kathey Marsden Assigned To: Mamta A. Satoor Priority: Minor Attachments: DERBY737_v1_diff_SYSCS_COMPRESS_TABLE.txt, DERBY737_v1_stat_SYSCS_COMPRESS_TABLE.txt There must be an entry in the SYSSTATISTICS table in order for the cardinality statistics in SYSSTATISTICS to be created with SYSCS_UTIL.SYSCS_COMPRESS_TABLE SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they don't exist. The only way to create them if the index was created on an empty table, seems to be to drop and recreate the index after the table has been loaded. The documentation will also need updating if this change is made. http://db.apache.org/derby/docs/10.1/tuning/ctunstats57373.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
[jira] Created: (DERBY-1964) Update the documentation of SYSCS_UTIL.SYSCS_COMPRESS_TABLE for the changes that went in as part of DERBY-737
Update the documentation of SYSCS_UTIL.SYSCS_COMPRESS_TABLE for the changes that went in as part of DERBY-737 - Key: DERBY-1964 URL: http://issues.apache.org/jira/browse/DERBY-1964 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.3.0.0 Reporter: Mamta A. Satoor Priority: Minor As part of DERBY-737 SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they do not exist, SYSCS_UTIL.SYSCS_COMPRESS_TABLE now will create statistics for indexes if they do not already exist. This needs to be documented. The changes went into 10.3 codeline when I created this documentation jira entry. The changes may get ported to prior releases. Please check DERBY-737 to see what all releases will need the documentation changes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1940) Removed Ease of Development API
[ http://issues.apache.org/jira/browse/DERBY-1940?page=all ] Daniel John Debrunner updated DERBY-1940: - Issue Type: Task (was: Bug) This is not a bug in Derby. Removed Ease of Development API --- Key: DERBY-1940 URL: http://issues.apache.org/jira/browse/DERBY-1940 Project: Derby Issue Type: Task Components: JDBC Affects Versions: 10.2.1.6 Reporter: Rick Hillegas Assigned To: Rick Hillegas Fix For: 10.2.2.0 Attachments: derby-1940-v01.diff The Ease of Development api has been removed from Java SE 6 and deferred till Java SE 7. This requires removing the corresponding support from Derby. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: Error messages
On 10/13/06, Manjula G Kutty [EMAIL PROTECTED] wrote:
Hi,
While browsing through the llist of error messages I found some of the
like below. I don't know the scenario in which those error messages are
thrown. Can any one give me some example?
28507=User ''{0}'' does not have {1} permission on table ''{2}''.''{3}''
for grant.
2850B=User ''{0}'' does not have execute permission on {1}
''{2}''.''{3}'' for grant.
Thanks
Manjula
Hi Manjula,
As far as I can see, these can never be generated - they'd only show
up if a variable 'forGrant' would be passed with value 'true' into the
methods where these errors are thrown.
( org.apache.derby.iapi.sql.dictionary.StatementTablePermission:check(...) and
org.apache.derby.iapi.sql.dictionary.StatementRoutinePermission:check(...)
respectively)
However, everyplace the methods are called, the parameter is hardcoded
to 'false'.
I cannot tell if this is because something is still planned to be
implemented, or that this is something that was put in but was
restructured and failed to come out.
I noticed in passing also one method that never appears to get used...
interface org.apache.derby.iapi.sql.dictionary.getColumnPermissions(
UUID, String privTypeStr, boolean, String)
implemented by
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.
Should bugs be created to clean this up? Or is there still work
outstanding that would use it?
Myrna
Re: HashJoinStrategy.feasible
Army, thanks for the detailed response. I should earlier have argued here that the use of the terms subquery and correlation in the analysis seems inappropriate. I understand that a subquery includes its own select clause, and that the term does not apply automatically to table expressions (though a select statement is a table expression). I'm perhaps being nitpicky about terminology, but it is important (to me, at least :-)) to distinguish between standard SQL semantics and implementation limitations/bugs. In this case, it doesn't appear that there are any sub-queries, but instead one cross join, two outer joins and a restriction (where clause). Repeating for easy reference your DDL: CREATE TABLE T ( A INT NOT NULL, B DECIMAL(10,3) NOT NULL, C VARCHAR(5) NOT NULL); INSERT INTO T VALUES (1, 1.0, '1'), (2, 2.0, '2'), (3, 3.0, '3'); CREATE TABLE S ( D INT NOT NULL, E DECIMAL(10,3) NOT NULL, F VARCHAR(5) NOT NULL); INSERT INTO S VALUES (2, 2.0, '2'), (3, 3.0, '3'), (4, 4.0, '4'); CREATE TABLE R ( G INT NOT NULL, H DECIMAL(10,3) NOT NULL, I VARCHAR(5) NOT NULL); INSERT INTO R VALUES (3, 3.0, '3'), (4, 4.0, '4'), (5, 5.0, '5'); CREATE TABLE TT ( J INT NOT NULL, K DECIMAL(10,3) NOT NULL, L VARCHAR(5) NOT NULL); INSERT INTO TT VALUES (2, 2.0, '2'), (3, 3.0, '3'), (4, 4.0, '4'); And the select statement: select t0.* from tt as T0, (t as T1 left outer join (s as T2 left outer join r as T3 on (T2.f = T3.i)) on (T1.b = T2.e)) where (T0.j=T3.g); The innermost table expression, (s as T2 left outer join r as T3 on (T2.f = T3.i)), produces a result with the following columns: t2.D INT NOT NULL t2.E DECIMAL(10,3) NOT NULL t2.F VARCHAR(5) NOT NULL t3.G INT t3.H DECIMAL(10,3) t3.I VARCHAR(5) And these rows: ij select * from s as T2 left outer join r as T3 on (T2.f = T3.i); D |E |F|G |H |I - 2 |2.000 |2|NULL |NULL|NULL 3 |3.000 |3|3 |3.000 |3 4 |4.000 |4|4 |4.000 |4 An implicit constraint is that if one of G, H or I is null, they are all null. The immediately enclosing table expression produces a result with the following columns: t1.A INT NOT NULL t1.B DECIMAL(10,3) NOT NULL t1.C VARCHAR(5) NOT NULL t2.D INT t2.E DECIMAL(10,3) t2.F VARCHAR(5) t3.G INT t3.H DECIMAL(10,3) t3.I VARCHAR(5) And these rows: ij select * from t as T1 left outer join (s as T2 left outer join r as T3 on (T2.f = T3.i)) on (T1.b = T2.e); A |B |C|D |E |F|G |H |I 1 |1.000 |1|NULL |NULL|NULL |NULL |NULL|NULL 2 |2.000 |2|2 |2.000 |2|NULL |NULL|NULL 3 |3.000 |3|3 |3.000 |3|3 |3.000 |3 An additional implicit constraint is that if one of D, E or F is null, then all of D, E, F, G, H and I are null. Note that there is no correlation between the left hand table expression, t as T1, and the right hand table expression, (s as T2 left outer I.e., there is no need to re-execute the right hand table expression because is the same everytime. Next (before the where clause) we have the cross join between the previous result and the table tt, producing a result with the following columns: t0.J INT NOT NULL t0.K DECIMAL(10,3) NOT NULL t0.L VARCHAR(5) NOT NULL t1.A INT NOT NULL t1.B DECIMAL(10,3) NOT NULL t1.C VARCHAR(5) NOT NULL t2.D INT t2.E DECIMAL(10,3) t2.F VARCHAR(5) t3.G INT t3.H DECIMAL(10,3) t3.I VARCHAR(5) And these rows: ij select * from tt as T0, (t as T1 left outer join (s as T2 left outer join r as T3 on (T2.f = T3.i)) on (T1.b = T2.e)); J |K |L|A |B |C|D |E |F|G |H |I --- 2 |2.000 |2|1 |1.000 |1|NULL |NULL|NULL |NULL |NULL|NULL 3 |3.000 |3|1 |1.000 |1|NULL |NULL|NULL |NULL |NULL|NULL 4 |4.000 |4|1 |1.000 |1|NULL |NULL|NULL |NULL |NULL|NULL 2 |2.000 |2|2 |2.000 |2|2 |2.000 |2|NULL |NULL|NULL 3 |3.000 |3|2 |2.000 |2|2 |2.000 |2|NULL |NULL|NULL 4 |4.000 |4|2 |2.000 |2|2 |2.000 |2|NULL |NULL|NULL 2 |2.000 |2|3 |3.000 |3
Re: Error messages
On 10/16/06, Myrna van Lunteren [EMAIL PROTECTED] wrote:Should bugs be created to clean this up? Or is there still work outstanding that would use it?I think they are left there intentionally for future work to support FOR GRANT OPTION.Yip
[jira] Commented: (DERBY-1839) Doc Review Updates - Ref Manual
[
http://issues.apache.org/jira/browse/DERBY-1839?page=comments#action_12442666 ]
Susan Cline commented on DERBY-1839:
Hi Laura,
Everything is correct except for the following;
TIMESTAMP:
The following clause returns the value 1998-12-25-17.12.30.00:
VALUES TIMESTAMP('1998-12-25', '17.12.30');
1
--
1998-12-25 17:12:30.0
It should be this:
The following clause returns the value 1998-12-25-17:12:30.0:
VALUES TIMESTAMP('1998-12-25', '17.12.30');
1
--
1998-12-25 17:12:30.0
Thanks,
Susan
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.2.0
Attachments: 1839_SQLstatements.diff, derby1839_functions1.diff,
derby1839_functions1.zip, derby1839_functions2.diff,
derby1839_functions2_html.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
[jira] Commented: (DERBY-1954) Update sysinfo output documentation in Tools and Utilities Guide
[ http://issues.apache.org/jira/browse/DERBY-1954?page=comments#action_12442667 ] Susan Cline commented on DERBY-1954: Hi Laura, Your changes looks good. Thanks a lot. Susan 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 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] Army Brown as a committer
+1
Re: Error messages
Yip Ng wrote: On 10/16/06, *Myrna van Lunteren* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Should bugs be created to clean this up? Or is there still work outstanding that would use it? I think they are left there intentionally for future work to support FOR GRANT OPTION. Yip Did you mean WITH GRANT OPTION ? In that case, I think it will be useful if these un-used messages can be re-worded to reflect that. -Rajesh
Re: [VOTE] Army Brown as a committer
Mike Matrigali: This vote is for establishing Army Brown as a committer for Derby. +1 I'm sort of surprised that he isn't already a committer. =) -- Anders Morken My opinions may have changed, but not the fact that I am right!
[jira] Commented: (DERBY-1893) Convert largedata/lobLengthTests.java to junit
[ http://issues.apache.org/jira/browse/DERBY-1893?page=comments#action_12442681 ] Knut Anders Hatlen commented on DERBY-1893: --- I have two comments to the patch (sorry I didn't notice before it was committed): - the suite method should have used suite.addTestSuite(LobLengthTest.class) instead of suite.addTest(new LobLengthTest(testXXX)). The way it is now, a new test case won't run automatically, and one might be led to belive that it succeeded when in fact it did not run. - the tearDown() method should set conn to null and call super.tearDown(). Tests not doing this have caused OutOfMemoryErrors before (DERBY-1845 and DERBY-1910). (It would be even better if the test class didn't have its own instance variable for the connection since the BaseJDBCTestClass already has many helper methods which remove the need for an explicit pointer to the connection.) Convert largedata/lobLengthTests.java to junit -- Key: DERBY-1893 URL: http://issues.apache.org/jira/browse/DERBY-1893 Project: Derby Issue Type: Sub-task Components: Test Reporter: Øystein Grøvlen Assigned To: Øystein Grøvlen Priority: Trivial Attachments: derby1893.diff, derby1893.stat, derby1893_v2.diff, derby1893_v2.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
[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_12442683 ]
Suresh Thalamati commented on DERBY-1953:
-
Hi Yip ,
Thanks for enhancing the patch , withe Bernt's suggestion. I am not able to
apply the patch cleanly, the changes in this patch are conflicting with some
other changes (most probably u'r derby-630 fix). Could you please resolve
the conflicts and post the patch again.
if there are no further comments from any one else. I will commit the patch.
Thanks
-suresh
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-stat01.txt,
derby1953-trunk-stat02.txt, derby1953-trunk-stat03.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: Error messages
On 10/16/06, Rajesh Kartha [EMAIL PROTECTED] wrote: Did you mean WITH GRANT OPTION ?In that case, I thinkit will be useful if these un-used messages canbe re-worded to reflect that.Yes, I mean WITH GRANT OPTION. =) Yip
[jira] Commented: (DERBY-737) SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they do not exist
[ http://issues.apache.org/jira/browse/DERBY-737?page=comments#action_12442684 ] Bryan Pendleton commented on DERBY-737: --- The merge to the 10.2 branch was straightforward, and my 10.2 derbyall test run was clean. I propose to commit this merged change to the 10.2 branch. SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they do not exist - Key: DERBY-737 URL: http://issues.apache.org/jira/browse/DERBY-737 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.1.3.1, 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.2.1.6, 10.0.2.2 Reporter: Kathey Marsden Assigned To: Mamta A. Satoor Priority: Minor Attachments: DERBY737_v1_diff_SYSCS_COMPRESS_TABLE.txt, DERBY737_v1_stat_SYSCS_COMPRESS_TABLE.txt There must be an entry in the SYSSTATISTICS table in order for the cardinality statistics in SYSSTATISTICS to be created with SYSCS_UTIL.SYSCS_COMPRESS_TABLE SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they don't exist. The only way to create them if the index was created on an empty table, seems to be to drop and recreate the index after the table has been loaded. The documentation will also need updating if this change is made. http://db.apache.org/derby/docs/10.1/tuning/ctunstats57373.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
[jira] Commented: (DERBY-1893) Convert largedata/lobLengthTests.java to junit
[ http://issues.apache.org/jira/browse/DERBY-1893?page=comments#action_12442685 ] Daniel John Debrunner commented on DERBY-1893: -- I was actually addressing the issues that Knut Anders raises in some cleanup related to DERBY-1952 Convert largedata/lobLengthTests.java to junit -- Key: DERBY-1893 URL: http://issues.apache.org/jira/browse/DERBY-1893 Project: Derby Issue Type: Sub-task Components: Test Reporter: Øystein Grøvlen Assigned To: Øystein Grøvlen Priority: Trivial Attachments: derby1893.diff, derby1893.stat, derby1893_v2.diff, derby1893_v2.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
[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:
--
Attachment: derby1953-trunk-stat04.txt
derby1953-trunk-diff04.txt
Attaching derby1953-trunk-diff04.txt. Previous patch conflicted with DERBY-183
and DERBY-630.
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: [jira] Commented: (DERBY-408) Fix formatting of manuals in PDF output
Hi, Laura, Thanks for this comment. I've been wondering about the tagging in the Working with Derby book -- I think it is often unconventional (should output be in italics?? I don't think so). There is a DITA - to - XSL-FO problem, as you say, but possibly the formatting should be cleaned up too. This would be a separate bug, though. I could file it (and fix it) if you think it would be worth while. I'm sending this offline as I don't know who contributed the WWD book -- it's good to have it and the content is very useful -- and I don't want to hurt their feelings. Kim Laura Stewart (JIRA) wrote On 10/16/06 12:25,: [ http://issues.apache.org/jira/browse/DERBY-408?page=comments#action_12442633 ] Laura Stewart commented on DERBY-408: - I don't believe that the documentation should use tags like bold b to force line breaks. Infact, in most cases there shouldn't be bold tags inside of codeblocks and syntax. Typically uppercase letters are used for the required SQL and lowercase letters for the variables such as index-name. Sometimes varname is used for the variables, which displays the text in italic. This sounds like a DITA - to - XSL-FO problem. 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.
[jira] Resolved: (DERBY-737) SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they do not exist
[ http://issues.apache.org/jira/browse/DERBY-737?page=all ] Bryan Pendleton resolved DERBY-737. --- Fix Version/s: 10.2.1.8 10.3.0.0 Resolution: Fixed Merged the trunk fix to the 10.2 branch and committed to subversion as revision 464683. SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they do not exist - Key: DERBY-737 URL: http://issues.apache.org/jira/browse/DERBY-737 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.1.3.1, 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.2.1.6, 10.0.2.2 Reporter: Kathey Marsden Assigned To: Mamta A. Satoor Priority: Minor Fix For: 10.2.1.8, 10.3.0.0 Attachments: DERBY737_v1_diff_SYSCS_COMPRESS_TABLE.txt, DERBY737_v1_stat_SYSCS_COMPRESS_TABLE.txt There must be an entry in the SYSSTATISTICS table in order for the cardinality statistics in SYSSTATISTICS to be created with SYSCS_UTIL.SYSCS_COMPRESS_TABLE SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they don't exist. The only way to create them if the index was created on an empty table, seems to be to drop and recreate the index after the table has been loaded. The documentation will also need updating if this change is made. http://db.apache.org/derby/docs/10.1/tuning/ctunstats57373.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
[jira] Updated: (DERBY-1839) Doc Review Updates - Ref Manual
[ http://issues.apache.org/jira/browse/DERBY-1839?page=all ] Laura Stewart updated DERBY-1839: - Attachment: derby1839_functions3.diff derby1839_functions_html3.zip Updated the TIMESTAMP file per Susan's comment. Hope that it is correct now :-) 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.2.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
Re: [jira] Commented: (DERBY-1954) Update sysinfo output documentation in Tools and Utilities Guide
Susan Cline (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1954?page=comments#action_12442667 ] Susan Cline commented on DERBY-1954: Hi Laura, Your changes looks good. Thanks a lot. I'll commit Laura's patch. -jean
Re: [jira] Commented: (DERBY-408) Fix formatting of manuals in PDF output
Hi Kim - I think that there is a LOT of tagging in the Derby docs that needs to be reviewed and corrected :-) One of the problems that Derby has is that there aren't any tagging standards. I want to propose some on the list and perhaps you can comment on your perspective and we can come to some consenscious which can then be documented on the Derby Documentation web page. I don't think the owner (whoever they are) will be offended if you open an issue to fix the tagging in WWD. And yes, I don' t think that italic is the correct format for output. Most DITA files that I have worked with use codeblock Laura On 10/16/06, Kim Haase [EMAIL PROTECTED] wrote: Hi, Laura, Thanks for this comment. I've been wondering about the tagging in the Working with Derby book -- I think it is often unconventional (should output be in italics?? I don't think so). There is a DITA - to - XSL-FO problem, as you say, but possibly the formatting should be cleaned up too. This would be a separate bug, though. I could file it (and fix it) if you think it would be worth while. I'm sending this offline as I don't know who contributed the WWD book -- it's good to have it and the content is very useful -- and I don't want to hurt their feelings. Kim Laura Stewart (JIRA) wrote On 10/16/06 12:25,: [ http://issues.apache.org/jira/browse/DERBY-408?page=comments#action_12442633 ] Laura Stewart commented on DERBY-408: - I don't believe that the documentation should use tags like bold b to force line breaks. Infact, in most cases there shouldn't be bold tags inside of codeblocks and syntax. Typically uppercase letters are used for the required SQL and lowercase letters for the variables such as index-name. Sometimes varname is used for the variables, which displays the text in italic. This sounds like a DITA - to - XSL-FO problem. 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. -- Laura Stewart
[jira] Commented: (DERBY-1954) Update sysinfo output documentation in Tools and Utilities Guide
[ http://issues.apache.org/jira/browse/DERBY-1954?page=comments#action_12442728 ] Jean T. Anderson commented on DERBY-1954: - Committed patch derby1954_1.diff to trunk, revision 464694, and merged to 10.2 branch, revision 464696. Thanks, Laura! 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 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
[jira] Updated: (DERBY-1954) Update sysinfo output documentation in Tools and Utilities Guide
[ http://issues.apache.org/jira/browse/DERBY-1954?page=all ] Jean T. Anderson updated DERBY-1954: Fix Version/s: 10.2.1.8 10.3.0.0 Derby Info: (was: [Patch Available]) 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.3.0.0, 10.2.1.8 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
[jira] Updated: (DERBY-1942) There exists difference between behavior of setNull(Types.TIME) and setTiime(null).
[ http://issues.apache.org/jira/browse/DERBY-1942?page=all ] Tomohito Nakayama updated DERBY-1942: - Derby Info: [Release Note Needed] There exists difference between behavior of setNull(Types.TIME) and setTiime(null). Key: DERBY-1942 URL: http://issues.apache.org/jira/browse/DERBY-1942 Project: Derby Issue Type: Bug Components: JDBC Reporter: Tomohito Nakayama Assigned To: Tomohito Nakayama Attachments: DERBY-1942.patch The result of setNull(java.sql.Types.TIME) for TIMESTAMP typed variable is regarded as error. However, the result of setTime(null) for TIMESTAMP typed variable is not regarded as error . see http://issues.apache.org/jira/browse/DERBY-1610#action_12436554 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1942) There exists difference between behavior of setNull(Types.TIME) and setTiime(null).
[ http://issues.apache.org/jira/browse/DERBY-1942?page=all ] Tomohito Nakayama updated DERBY-1942: - Derby Info: [Existing Application Impact, Release Note Needed] (was: [Release Note Needed]) There exists difference between behavior of setNull(Types.TIME) and setTiime(null). Key: DERBY-1942 URL: http://issues.apache.org/jira/browse/DERBY-1942 Project: Derby Issue Type: Bug Components: JDBC Reporter: Tomohito Nakayama Assigned To: Tomohito Nakayama Attachments: DERBY-1942.patch The result of setNull(java.sql.Types.TIME) for TIMESTAMP typed variable is regarded as error. However, the result of setTime(null) for TIMESTAMP typed variable is not regarded as error . see http://issues.apache.org/jira/browse/DERBY-1610#action_12436554 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1839) Doc Review Updates - Ref Manual
[ http://issues.apache.org/jira/browse/DERBY-1839?page=comments#action_12442733 ] Susan Cline commented on DERBY-1839: We're good to go! Thanks, Susan 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.2.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
Incorrect code in NetworkDerbyControlImpl.shutdown()??
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?
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
Network server start up time - why 50+ seconds sometimes?
I'm running the JUnit test suite All using Junit test runners with several tests that use the NetworkServerTestSetup to start and stop the server. The server is started and stopped around five times. With a timeout wait of 60 seconds for the server to start I see one or two failures due to the server not starting in time. Looking more closely I see that either the server starts in less than 200ms or that it takes 50+ seconds. Any thoughts on why this binary mode, seems close to a possible 60 second system timeout mechanism. Is there some cleanup the network server could be failing to do, or could an open client side connection cause this? Increasing the wait time to 180 seconds means no failures are seen, but continue to see that once or twice the server takes 50-100 seconds to start. Dan. PS. This is on Windows.
Re: [jira] Commented: (DERBY-408) Fix formatting of manuals in PDF output
Hi Kim - Please do open an issue on WWD (Working With Derby) and correct these problems. Having the lines run together as shown in your comment on 10/12 is awful. Several people contributed to the document in the form of input and reviews, I did the original contribution and take no offense to any changes members of the community deem appropriate (this change is more 'badly needed' than 'deem appropriate'). Halley has already done some clean-up (see: Derby-1394). I 'winged' the formatting in the codeblock sections in hopes it would be easier to read the longer interactive examples but I'm not certain it made a big difference. And now, of course, it is broken. I also noted Derby-1948 filed today (http://issues.apache.org/jira/browse/DERBY-1948 ) caused by the changes in the DEMO directory structure - the PROGRAMS folder did not exist in early builds of 10.2 - references to $DERBY_HOME/demo/subdir need to be changed to $DERBY_HOME/demo/programs/subdir. While you have the files open could you correct this as well? I don't know when I could get around to making even such a small correction. And; Thanks for the kind words about the document. Kim Haase wrote: Hi, Laura, Thanks for this comment. I've been wondering about the tagging in the Working with Derby book -- I think it is often unconventional (should output be in italics?? I don't think so). There is a DITA - to - XSL-FO problem, as you say, but possibly the formatting should be cleaned up too. This would be a separate bug, though. I could file it (and fix it) if you think it would be worth while. I'm sending this offline as I don't know who contributed the WWD book -- it's good to have it and the content is very useful -- and I don't want to hurt their feelings. Kim Laura Stewart (JIRA) wrote On 10/16/06 12:25,: [ http://issues.apache.org/jira/browse/DERBY-408?page=comments#action_12442633 ] Laura Stewart commented on DERBY-408: - I don't believe that the documentation should use tags like bold b to force line breaks. Infact, in most cases there shouldn't be bold tags inside of codeblocks and syntax. Typically uppercase letters are used for the required SQL and lowercase letters for the variables such as index-name. Sometimes varname is used for the variables, which displays the text in italic. This sounds like a DITA - to - XSL-FO problem. === SNIP ==
[jira] Created: (DERBY-1965) NetworkServerControlImpl never closes the socket or streams it opens in setUpSocket.
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 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] Updated: (DERBY-1965) NetworkServerControlImpl never closes the socket or streams it opens in setUpSocket.
[ http://issues.apache.org/jira/browse/DERBY-1965?page=all ] Daniel John Debrunner updated DERBY-1965: - Attachment: derby1965_diff.txt Quick patch - not run tests on it yet. 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-1886) Remove junit.jar from the source distributions.
[ http://issues.apache.org/jira/browse/DERBY-1886?page=all ] Andrew McIntyre reassigned DERBY-1886: -- Assignee: Rick Hillegas Remove junit.jar from the source distributions. --- Key: DERBY-1886 URL: http://issues.apache.org/jira/browse/DERBY-1886 Project: Derby Issue Type: Improvement Components: Build tools Affects Versions: 10.2.1.6 Reporter: Rick Hillegas Assigned To: Rick Hillegas Fix For: 10.2.1.6 Attachments: derby-1886-v01.diff The junit.jar file is not under source control and is distributed under a non-Apache license. However, it appears in our source distributions. We should either remove it from the source distributions or add some verbiage to the NOTICE file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-457) Support for equivalent of Oracle's describe command
[ http://issues.apache.org/jira/browse/DERBY-457?page=comments#action_12442763 ] James F. Adams commented on DERBY-457: -- I believe this can be closed. This functionality appears to be implemented by DERBY-1164. Support for equivalent of Oracle's describe command --- Key: DERBY-457 URL: http://issues.apache.org/jira/browse/DERBY-457 Project: Derby Issue Type: New Feature Components: SQL Affects Versions: 10.0.2.1 Reporter: simmi iyer Priority: Minor Most of the databases provide a descibe command that displays the columns and their data types for a table. Using dblookup for this purpose is too heavy-duty. Dblookup is more like reverse engineering tool i.e. generating schema description from a schema. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-457) Support for equivalent of Oracle's describe command
[ http://issues.apache.org/jira/browse/DERBY-457?page=all ] Andrew McIntyre resolved DERBY-457. --- Fix Version/s: 10.2.1.8 Resolution: Duplicate Agreed. Resolving as duplicate of DERBY-1164. Support for equivalent of Oracle's describe command --- Key: DERBY-457 URL: http://issues.apache.org/jira/browse/DERBY-457 Project: Derby Issue Type: New Feature Components: SQL Affects Versions: 10.0.2.1 Reporter: simmi iyer Priority: Minor Fix For: 10.2.1.8 Most of the databases provide a descibe command that displays the columns and their data types for a table. Using dblookup for this purpose is too heavy-duty. Dblookup is more like reverse engineering tool i.e. generating schema description from a schema. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1839) Doc Review Updates - Ref Manual
[ http://issues.apache.org/jira/browse/DERBY-1839?page=comments#action_12442766 ] Jean T. Anderson commented on DERBY-1839: - Committed patch derby1839_functions3.diff to trunk, revision 464772, and merged to 10.2 branch, revision 464773. Thanks, Laura! 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.2.0, 10.2.1.8, 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
[jira] Updated: (DERBY-1839) Doc Review Updates - Ref Manual
[ http://issues.apache.org/jira/browse/DERBY-1839?page=all ] Jean T. Anderson updated DERBY-1839: Fix Version/s: 10.2.1.8 10.3.0.0 Derby Info: (was: [Patch Available]) 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.2.0, 10.2.1.8, 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
[jira] Created: (DERBY-1966) NetworkServer startup can take 50+ seconds if a client holds an open connection to the previous server booted within the same vm
NetworkServer startup can take 50+ seconds if a client holds an open connection to the previous server booted within the same vm Key: DERBY-1966 URL: http://issues.apache.org/jira/browse/DERBY-1966 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.3.0.0 Environment: Windows XP - IBM JVM 1.4.2 Reporter: Daniel John Debrunner Seen when a client in the same jvm held a open connection to a previously booted network server within the same jvm. Order would be: boot server client connect to server (hold onto connection and don't close) shutdown server boot server -- this boot will take 50+ seconds -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
