[jira] Commented: (DERBY-1473) Add cut-off and truncation logic to streaming classes in the embedded driver
[
http://issues.apache.org/jira/browse/DERBY-1473?page=comments#action_12428053 ]
Knut Anders Hatlen commented on DERBY-1473:
---
I have started reviewing the patch. I haven't finished the review yet,
but I'll post the comments I have so far.
- CharAlphabet.java contains some UTF-8 encoded characters, and I had
to change my locale to be able to compile it. These characters
should probably be escaped.
- RawToBinaryFormatStream(InputStream, int) first checks whether
length is less than zero, and throws an exception if it is. After
that check, there's a new one if (length = 0) {...} else {...},
but at that time length is guaranteed to be greater than or equal to
zero.
- RawToBinaryFormatStream and ReaderToUTF8Stream sometimes throw
IllegalArgumentException. I not sure whether I think this is a good
or a bad approach. I think it is good because internal errors in
Derby will be exposed and can be fixed. I also think it not so good
because the conditions that are checked are not critical, and it
would make sense to carry on in insane mode (for instance, typeName
== null won't be a problem until an error message using the type
name is constructed, and maximumLength 0 will be treated more or
less as 0). I think either it should be rewritten using
SanityManager.ASSERT, or it should have a comment saying why
IllegalArgumentException is used and that it won't be exposed to the
users unless there's a programming error in Derby.
- In RawToBinaryFormatStream.checkSufficientData(), the body of the
if (c != -1) clause has become very large. I think it would be
clearer if it had braces around it (although the diff would be three
lines longer).
Thanks.
Add cut-off and truncation logic to streaming classes in the embedded driver
Key: DERBY-1473
URL: http://issues.apache.org/jira/browse/DERBY-1473
Project: Derby
Issue Type: Improvement
Components: JDBC
Affects Versions: 10.2.0.0
Reporter: Kristian Waagan
Assigned To: Kristian Waagan
Fix For: 10.2.0.0
Attachments: derby-1473-1a-streaming.diff,
derby-1473-1a-streaming.stat, derby-1473-2a-streamingtests.diff,
derby-1473-2a-streamingtests.stat
When streaming data to Derby, the application stream will be wrapped in a
Derby-specific stream to convert the data to the correct representation. At a
minimum, this consists of getting the data to the on-disk format used by
Derby.
The wrapping stream can be extended to provide the following features at an
earlier stage:
a) Data cut-off when the maximum allowed size is exceeded
b) Truncation of trailing blanks where allowed
Both features can reduce the amount of data needed to be kept in memory on
insertion.
Implementing this will require additional column/data type information in the
streaming class(es). The implementation must be able to handle streams for
which the length is specified and also streams with unknown/unspecified
length.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1655) Document XML functionality for 10.2
[ http://issues.apache.org/jira/browse/DERBY-1655?page=all ] Laura Stewart updated DERBY-1655: - Derby Info: [Patch Available] Document XML functionality for 10.2 --- Key: DERBY-1655 URL: http://issues.apache.org/jira/browse/DERBY-1655 Project: Derby Issue Type: Task Components: Documentation Affects Versions: 10.2.0.0 Reporter: A B Assigned To: Laura Stewart Fix For: 10.2.0.0 Attachments: ctoolsimport27052.html, derby1655_devguide.diff, derby1655_devguide_html.zip, derby1655_ref.diff, derby1655_ref_html.zip, derby1655_tools_html.diff, derby1655_tuning.diff, derby1655_tuning_html.zip, DerbyXMLDoc_v1.html, DerbyXMLDoc_v2.html DERBY-334 and DERBY-688 have added an XML datatype and four XML operators to Derby. These are all going to be exposed to the user for general use as part of the 10.2. release, so the datatype and operators need to be documented accordingly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1652) Update trigger updating the same rows as the original update does not throw an exception ERROR 54038: Maximum depth of nested triggers was exceeded as it should
[ http://issues.apache.org/jira/browse/DERBY-1652?page=comments#action_12428060 ] Yip Ng commented on DERBY-1652: --- For the updatableResultSet.java, yes, it will still perform the action described because the triggers are also modified to preserve the original intention of the test. The master output for triggerGeneral.sql were incorrect for those testcases, so I just replaced them with the expected results (I thought they were negative tests with wrong results). I tried to preserve the original testcase intent whenever I can but the column list specification won't work on those testcases since they are using an after insert trigger. And that test file already have tests to insert to another table from the trigger action, so now those tests really become negative... Update trigger updating the same rows as the original update does not throw an exception ERROR 54038: Maximum depth of nested triggers was exceeded as it should --- Key: DERBY-1652 URL: http://issues.apache.org/jira/browse/DERBY-1652 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.0.2.0, 10.2.0.0, 10.1.3.1 Reporter: Kathey Marsden Assigned To: Yip Ng Fix For: 10.2.0.0, 10.1.3.2 Attachments: derby1652-10.1.3-diff.txt, derby1652-10.1.3-stat.txt, derby1652-trunk-diff01.txt, derby1652-trunk-stat01.txt Execution of an update trigger that updates the same row as the original update will recurse forever and exceed the maximum nesting level of 16 so should throw the exception: ERROR 54038: Maximum depth of nested triggers was exceeded However, it does not always throw the exception. For example: CREATE TABLE TEST ( TESTID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1), INFO INTEGER NOT NULL, TIMESTAMP TIMESTAMP NOT NULL DEFAULT '1980-01-01-00.00.00.00' ); CREATE TRIGGER UPDATE_TEST AFTER UPDATE ON TEST REFERENCING OLD AS OLD FOR EACH ROW MODE DB2SQL UPDATE TEST SET TIMESTAMP = CURRENT_TIMESTAMP WHERE TESTID = OLD.TESTID; INSERT INTO TEST (INFO) VALUES (1), (2), (3); UPDATE TEST SET INFO = 1 WHERE TESTID = 2; Does not throw an exception: However, If the derby jars are updated to a new version, the correct exception is thrown. Replace derby jars with new version Execute the following in ij: UPDATE TEST SET INFO = 1 WHERE TESTID = 2; ERROR 54038: Maximum depth of nested triggers was exceeded. Note: This issue stemmed from the Invalid issue, DERBY-1603, because a user hit the exception after upgrade and thought the exception after upgrade, not the lack of exception before upgrade was the problem. This may be a common user error, so we need a release note to help mitigate the issue.I will add one shortly after confirming the correct trigger syntax. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1551) Update documentation to indicate procedures can be called from triggers (DERBY-551)
[ http://issues.apache.org/jira/browse/DERBY-1551?page=all ] Laura Stewart closed DERBY-1551. Resolution: Fixed The doc updated have been reviewed, committed, and confirmed. Closing this issue. Update documentation to indicate procedures can be called from triggers (DERBY-551) --- Key: DERBY-1551 URL: http://issues.apache.org/jira/browse/DERBY-1551 Project: Derby Issue Type: Task Components: Documentation Reporter: Deepa Remesh Assigned To: Laura Stewart Fix For: 10.2.0.0 Attachments: derby1551_ref.diff, derby1551_ref2.diff, derby1551_ref_html.zip, derby1551_ref_html2.zip Derby Reference manual has to be updated with following information: * Section CREATE TRIGGER statement -- Triggered-SQL-statement - The following line It must not execute a CALL statement. needs to be removed - The following line Before triggers cannot have INSERT, UPDATE or DELETE statements as their action. needs to be replaced to indicate before triggers also cannot call procedures that modify SQL data. It can be replaced with something like Before triggers cannot have INSERT, UPDATE or DELETE statements or calls to procedures that modify SQL data as their action. * Section SQLState and error message reference - Message text for X0Y69 has to be changed to value is not supported in trigger triggerName. - An additional row to be added for 42Z9D with following message text Procedures that modify SQL data are not allowed in BEFORE triggers. If there are any other places where the documentation needs to be updated for DERBY-551, please post it to this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1646) Documentation to address Grant/Revoke Authorization for views/triggers/constraints/routines(DERBY-1330)
[ http://issues.apache.org/jira/browse/DERBY-1646?page=comments#action_12428062 ] Laura Stewart commented on DERBY-1646: -- This documentation issue is tied to Derby1057. I believe that all of the documentation requirements for 1646 have been addressed in the patches for 1057. I would like to close 1646. Documentation to address Grant/Revoke Authorization for views/triggers/constraints/routines(DERBY-1330) --- Key: DERBY-1646 URL: http://issues.apache.org/jira/browse/DERBY-1646 Project: Derby Issue Type: New Feature Components: Documentation Affects Versions: 10.2.0.0 Reporter: Mamta A. Satoor Assigned To: Laura Stewart Creating a separate jira entry for documentation of Grant/Revoke Authorization for views/triggers/constraints/routines(Engine changes are going as part of DERBY-1330). Will link this jira entry to DERBY-1330 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1520) Document new SYSCS_DIAG tables
[ http://issues.apache.org/jira/browse/DERBY-1520?page=comments#action_12428066 ] Laura Stewart commented on DERBY-1520: -- I read Derby571 and looked up org.apache.derby.diag.LockTable in the docs. It appears only one time. Please help me understand this documentation requirement... Do you simply want the new table names to replace the old table names or is there more that you want documented from the javadoc? Document new SYSCS_DIAG tables -- Key: DERBY-1520 URL: http://issues.apache.org/jira/browse/DERBY-1520 Project: Derby Issue Type: Sub-task Components: Documentation Affects Versions: 10.2.0.0 Reporter: Stan Bradbury See comments for DERBY-571 for initial documentation discussion. The new tables (mapped to the old Diagnostic VTIs) are: The old style syntax will remain in place for 10.2, but become deprecated. The tables to be implemented in this change are: SYSCS_DIAG.LOCK_TABLE replaces org.apache.derby.diag.LockTable SYSCS_DIAG.STATEMENT_CACHE replaces org.apache.derby.diag.StatementCache SYSCS_DIAG.TRANSACTION_TABLE replaces org.apache.derby.diag.TransactionTable SYSCS_DIAG.ERROR_MESSAGES replaces org.apache.derby.diag.ErrorMessages The information about the tables can be found in the javadoc for the class listed above. That can be found at: http://db.apache.org/derby/javadoc/engine/ click on the org.apache.derby.diag link in the Packages table, then select each class, e.g. LockTable to see the info. -- 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: How to commit documentation patches?
Andrew McIntyre wrote: On 8/14/06, Daniel John Debrunner [EMAIL PROTECTED] wrote: [SNIP] Seems like we could get documentation patches in quicker if all the committers could handle them, rather than the the two or three who submit these patches today. Let's scale with the size of the community. Is there a write-up somewhere on how to do this? There is this page, which should describe most of what you need: http://db.apache.org/derby/manuals/dita.html It's hiding in the drop-down box off the left when you click the Documentation tab as DITA source. I think a link from the main documentation page might help make this easier to find. I agree, it is too hard to find the information you need when you want to become a new doc contributor or committer. One thing I noticed the first time I wanted to contribute a doc patch, was that on the Community tab/page [1], I found no mention of documentation source, patches, or links to relevant doc information in the section called Contribute Code or Documentation. The information there is very code-centric, as are the various wiki pages that are linked to from that page. -- John [1] http://db.apache.org/derby/derby_comm.html#Contribute+Code+or+Documentation
Explanation of documentation file names (was :Re: How to commit documentation patches?)
Laura Stewart wrote: As someone who has recently started to make contributions to the Derby docs, I have found a few holes in what is written on that page. After 10.2, I plan to make some updates to it, including proposing some standards, and an explanation of the file names (yes they are confusing :-) Hello Laura, I'm planning to take on a documentation task, which involves converting HTML files to the DITA XML format. I'm getting ready for that now, but I too don't understand the naming of the source files. There seems to be some prefixes: * 'c', 'r' and 't'. Not quite sure what these are. * 'dev', 'tools', 'tuning', 'ref' These indicate which manual the file belongs to. And, the great mystery, what do all the digits mean? Are they generated by a (deprecated) tool, are they random? For instance, 'rrefexcept71493.dita'. Can anyone please explain the naming scheme used for documentation source files? Thanks, -- Kristian I am not a committer so I would need someone who is to help me understand the steps required for committing doc info so that I can write that up for the community.
[jira] Commented: (DERBY-1693) Out of Memory Error with derby.language.logStatementText=true
[ http://issues.apache.org/jira/browse/DERBY-1693?page=comments#action_12428074 ] Kristian Waagan commented on DERBY-1693: I think I have seen the same issue earlier. My mind might be playing a trick on me, but I mean to remember the problem was that the statement text logging mechanism tries to log the contents of LOBs. Based on my testing, insertion of a 10 MB clob fails without tracing (this will change when some fixes get in), which may support the observation that insertion of a 5 MB clob fails if its content is cloned when being logged. 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.0.0 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 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
[jira] Updated: (DERBY-1559) when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB
[ http://issues.apache.org/jira/browse/DERBY-1559?page=all ] Andreas Korneliussen updated DERBY-1559: Attachment: DERBY-1559v2.diff Attached is an updated patch which preserves the changes in DERBY-1535 when receiving multiple EXTDTA objects. when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB Key: DERBY-1559 URL: http://issues.apache.org/jira/browse/DERBY-1559 Project: Derby Issue Type: Sub-task Components: Network Server Affects Versions: 10.2.0.0 Reporter: Andreas Korneliussen Assigned To: Andreas Korneliussen Attachments: DERBY-1559.diff, DERBY-1559.stat, DERBY-1559v2.diff When streaming a BLOB from the Network Client to the Network Server, the Network server currently read all the data from the stream and put it into a byte array. The blob data is then inserted into the DB by using PreparedStatement.setBytes(..) and later PreparedStatement.execute() To avoid OutOfMemoryError if the size of the Blob is than total memory in the VM, we could make the network server create a stream which reads data when doing PreparedStatement.execute(). The DB will then stream the BLOB data directly from the network inputstream into the disk. I intent to make a patch which does this if there is only one EXTDTA object (BLOB) sent from the client in the statement, as it will simplify the implementation. Later this can be improved further to include CLOBs, and possibly to include the cases where there are multiple EXTDTA objects. -- CLOBs are more complex, as there need to be some character encoding. This can be achieved by using a InputStreamReader, and use PreparedStatement.setCharacterStream(..). However the size of the stream is not necessarily the same as the size of the raw binary data, and to do this for CLOBs, I would need the embedded prepared statements to support the new setCharacterStream() overloads in JDBC4 (which do not include a length atribute) -- Multiple EXTDATA objects are also more complex, since one would need to have fully read the previous object ,before it is possible to read the next. -- -- 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: Explanation of documentation file names (was :Re: How to commit documentation patches?)
Kristian Waagan wrote: There seems to be some prefixes: * 'c', 'r' and 't'. Not quite sure what these are. These are explained here: http://db.apache.org/derby/manuals/dita.html#DITA+file+names All DITA topics are classified as either concepts, tasks, or reference material. Thus, every file begins with either a c, t, or r. In addition, the letters that appear immediately after this first one provide a shorthand id for the manual. For example, the Getting Started with Derby manual uses gs, so a reference topic DITA file in that manual will start with rgs. * 'dev', 'tools', 'tuning', 'ref' These indicate which manual the file belongs to. And, the great mystery, what do all the digits mean? Are they generated by a (deprecated) tool, are they random? For instance, 'rrefexcept71493.dita'. On the same web page, I found: Subsequent letters in the file name may provide hints at the topic's section within the manual, as well as numbers distinguishing it from other DITA files. It seems that the numbers are random, but perhaps someone with DITA- or relevant historical knowledge has more details... -- John
Re: Explanation of documentation file names (was :Re: How to commit documentation patches?)
Hi Kristian - Answers below... On 8/15/06, Kristian Waagan [EMAIL PROTECTED] wrote: Laura Stewart wrote: As someone who has recently started to make contributions to the Derby docs, I have found a few holes in what is written on that page. After 10.2, I plan to make some updates to it, including proposing some standards, and an explanation of the file names (yes they are confusing :-) Hello Laura, I'm planning to take on a documentation task, which involves converting HTML files to the DITA XML format. I'm getting ready for that now, but I too don't understand the naming of the source files. There seems to be some prefixes: * 'c', 'r' and 't'. Not quite sure what these are. *** (LS) These refer to the type of topic - concept, reference, and task. Unfortunately there aren't any guidelines formally posted on the Derby site as to the content for these. After 10.2 I hope to propose some guidelines that we can all follow... if you need some help before that time, just ask :-) * 'dev', 'tools', 'tuning', 'ref' These indicate which manual the file belongs to. *** (LS) Yes. That is correct. And, the great mystery, what do all the digits mean? Are they generated by a (deprecated) tool, are they random? For instance, 'rrefexcept71493.dita'. ***(LS) I believe that these file names were generated when the documentation was converted to DITA. That is before my time :-) What I have adopted as a naming convention is to try to use general terms. For example, I recently documented some new math functions. Some of the existing names had numerical endings and some had the word func at the end. The problem with putting func at the end is that the files are then scattered all over the place. Instead I put the category of info earlier in the name, so that the functions are all together (at least the new ones that I added). So I used the following: r = reference topic ref = Reference Manual func = function xxx = is the name of the actual function (sometimes abbreviated) and it should unique One of the functions was FLOOR, so the file name is rreffuncfloor. Can anyone please explain the naming scheme used for documentation source files? *** (LS) I hope that this helps. There isn't a limitation in the number of characters that you can use in a DITA file name... the names should be unique. I use the xxx to make the names unique. -- Laura Stewart
[jira] Commented: (DERBY-1114) derbynet/testSecMec.java fails intermittently and test exits mysteriously when server is shutdown as part of the testrun.
[ http://issues.apache.org/jira/browse/DERBY-1114?page=comments#action_12428101 ] Kathey Marsden commented on DERBY-1114: --- With all jvms I have tried and for quite a while I have seen this failure on my machine with Windows XP. I think it actually started when I upgraded my machine to Windows XP from Windows 2000, but I am not totally sure of that. It occurs with both classes and jars, with both derby client and jcc and is not intermittent. The test fails every time. I am attaching the test output (testSecMec_test_output.zip) to confirm that it is the same thing, but it sure seems like it because as Sunitha indicated the derby.log only shows two shutdown messages, instead of four. The JVM for this run is: java -version ava version 1.5.0 ava(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) BM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20060504 (JIT enabled) 9VM - 20060501_06428_lHdSMR IT - 20060428_1800_r8 C - 20060501_AA) CL - 20060511a OS is Windows XP Professional version 2002 Service Pack 2 All Sun and IBM jdk's that I have tried on this machine have the same failure, I am retiring this machine so thought I would record these results in case someone else hit the issue. Sadly, I don't have a solution to offer. One thing I tried, because I know it has caused other issues in the past was switching the test to just use port 1527 instead of 2. That made no difference. When I set up my new machine I will see if I have the same problem. derbynet/testSecMec.java fails intermittently and test exits mysteriously when server is shutdown as part of the testrun. - Key: DERBY-1114 URL: http://issues.apache.org/jira/browse/DERBY-1114 Project: Derby Issue Type: Bug Components: Network Server, Test Affects Versions: 10.2.0.0 Environment: Java Version:1.4.2_06 Java Vendor: Sun Microsystems Inc. Java home: /usr/local/lib/j2sdk1.4.2_06/jre OS name: Linux OS architecture: i386 OS version: 2.4.21-27.0.2.ELsmp Reporter: Sunitha Kambhampati Assigned To: Bryan Pendleton Priority: Minor Attachments: Derby1114.diff.txt, Stdout.java The test derbynet/testSecMec.java fails intermittently in a strange way that the test actually exits before finishing the full test. This issue was noticed by Bryan when he ran derbyall with the derby-1080 fix. Some discussion and analysis that has been done is in Derby-1080. Please read comments in DERBY-1080. Some main links in http://issues.apache.org/jira/browse/DERBY-1080#action_12370260 http://issues.apache.org/jira/browse/DERBY-1080#action_12370374 In short: the test does some switching of System.out and System.err streams before calling networkserver.shutdown. This code was added to this test as part of fix for derby-273. for some reason, the networkserver.shutdown call makes the test to exit. One theory is that the network server.shutdown is causing the standard out streams to close and thus the test exits. -- Need to investigate what is the cause for this intermittent failure and how/why networkserver.shutdown is closing the stream or making the test to exit prematurely. -- 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-1114) derbynet/testSecMec.java fails intermittently and test exits mysteriously when server is shutdown as part of the testrun.
[ http://issues.apache.org/jira/browse/DERBY-1114?page=all ] Kathey Marsden reopened DERBY-1114: --- have to reopen this to add an attachment. derbynet/testSecMec.java fails intermittently and test exits mysteriously when server is shutdown as part of the testrun. - Key: DERBY-1114 URL: http://issues.apache.org/jira/browse/DERBY-1114 Project: Derby Issue Type: Bug Components: Network Server, Test Affects Versions: 10.2.0.0 Environment: Java Version:1.4.2_06 Java Vendor: Sun Microsystems Inc. Java home: /usr/local/lib/j2sdk1.4.2_06/jre OS name: Linux OS architecture: i386 OS version: 2.4.21-27.0.2.ELsmp Reporter: Sunitha Kambhampati Assigned To: Bryan Pendleton Priority: Minor Attachments: Derby1114.diff.txt, Stdout.java The test derbynet/testSecMec.java fails intermittently in a strange way that the test actually exits before finishing the full test. This issue was noticed by Bryan when he ran derbyall with the derby-1080 fix. Some discussion and analysis that has been done is in Derby-1080. Please read comments in DERBY-1080. Some main links in http://issues.apache.org/jira/browse/DERBY-1080#action_12370260 http://issues.apache.org/jira/browse/DERBY-1080#action_12370374 In short: the test does some switching of System.out and System.err streams before calling networkserver.shutdown. This code was added to this test as part of fix for derby-273. for some reason, the networkserver.shutdown call makes the test to exit. One theory is that the network server.shutdown is causing the standard out streams to close and thus the test exits. -- Need to investigate what is the cause for this intermittent failure and how/why networkserver.shutdown is closing the stream or making the test to exit prematurely. -- 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-1114) derbynet/testSecMec.java fails intermittently and test exits mysteriously when server is shutdown as part of the testrun.
[ http://issues.apache.org/jira/browse/DERBY-1114?page=all ] Kathey Marsden updated DERBY-1114: -- Attachment: testSecMec_test_output.zip This is the test output from running the testSecMec.java test with derby client. The test seems to exit after two itterations of bringing the server up and down. This was run on the trunk At revision 431576 derbynet/testSecMec.java fails intermittently and test exits mysteriously when server is shutdown as part of the testrun. - Key: DERBY-1114 URL: http://issues.apache.org/jira/browse/DERBY-1114 Project: Derby Issue Type: Bug Components: Network Server, Test Affects Versions: 10.2.0.0 Environment: Java Version:1.4.2_06 Java Vendor: Sun Microsystems Inc. Java home: /usr/local/lib/j2sdk1.4.2_06/jre OS name: Linux OS architecture: i386 OS version: 2.4.21-27.0.2.ELsmp Reporter: Sunitha Kambhampati Assigned To: Bryan Pendleton Priority: Minor Attachments: Derby1114.diff.txt, Stdout.java, testSecMec_test_output.zip The test derbynet/testSecMec.java fails intermittently in a strange way that the test actually exits before finishing the full test. This issue was noticed by Bryan when he ran derbyall with the derby-1080 fix. Some discussion and analysis that has been done is in Derby-1080. Please read comments in DERBY-1080. Some main links in http://issues.apache.org/jira/browse/DERBY-1080#action_12370260 http://issues.apache.org/jira/browse/DERBY-1080#action_12370374 In short: the test does some switching of System.out and System.err streams before calling networkserver.shutdown. This code was added to this test as part of fix for derby-273. for some reason, the networkserver.shutdown call makes the test to exit. One theory is that the network server.shutdown is causing the standard out streams to close and thus the test exits. -- Need to investigate what is the cause for this intermittent failure and how/why networkserver.shutdown is closing the stream or making the test to exit prematurely. -- 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: publishing 10.2.1.0 to the Apache mirrors
Thanks, Jean. I will stop putting effort into this one. Regards, -Rick Jean T. Anderson wrote: Jean T. Anderson wrote: Rick Hillegas wrote: ... I don't know. It was suggested last week that we publish the beta to the mirrors to broaden its exposure. The intention wasn't to claim that it was GA-ready. I'm trying to figure out what is entailed in publishing a beta to the Apache mirrors. Has this been done before? Maybe I should copy the distribution to svn.apache.org rather than www.apache.org? I'm muddled by the description at http://www.apache.org/dev/mirrors.html. anything that is put on the asf mirrors must be voted on, approved by the pmc, signed etc. The asf doesn't require that a distribution be GA ready. Rick, earlier in another thread [1] you wrote: I don't think that this beta can become a release. It has some serious defects, including the licensing issues. However, those defects do not prevent users from testing the completed features. I'm hoping we will get significant feedback during this beta period so that the next distribution can be a serious release candidate No, this should not go up on the mirrors. -jean [1] http://mail-archives.apache.org/mod_mbox/db-derby-dev/200608.mbox/[EMAIL PROTECTED]
[jira] Commented: (DERBY-1473) Add cut-off and truncation logic to streaming classes in the embedded driver
[ http://issues.apache.org/jira/browse/DERBY-1473?page=comments#action_12428131 ] Knut Anders Hatlen commented on DERBY-1473: --- I have reviewed the rest of the patch, and I have no more comments. Add cut-off and truncation logic to streaming classes in the embedded driver Key: DERBY-1473 URL: http://issues.apache.org/jira/browse/DERBY-1473 Project: Derby Issue Type: Improvement Components: JDBC Affects Versions: 10.2.0.0 Reporter: Kristian Waagan Assigned To: Kristian Waagan Fix For: 10.2.0.0 Attachments: derby-1473-1a-streaming.diff, derby-1473-1a-streaming.stat, derby-1473-2a-streamingtests.diff, derby-1473-2a-streamingtests.stat When streaming data to Derby, the application stream will be wrapped in a Derby-specific stream to convert the data to the correct representation. At a minimum, this consists of getting the data to the on-disk format used by Derby. The wrapping stream can be extended to provide the following features at an earlier stage: a) Data cut-off when the maximum allowed size is exceeded b) Truncation of trailing blanks where allowed Both features can reduce the amount of data needed to be kept in memory on insertion. Implementing this will require additional column/data type information in the streaming class(es). The implementation must be able to handle streams for which the length is specified and also streams with unknown/unspecified length. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1696) transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset
transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset - Key: DERBY-1696 URL: http://issues.apache.org/jira/browse/DERBY-1696 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.0.0, 10.2.2.0, 10.3.0.0 Reporter: Andreas Korneliussen If an application does the following: Statement s = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_UPDATABLE); ResultSet rs = s.executeQuery(select * from t1); rs.afterLast(); rs.last(); rs.next(); After doing this in transaction isolation level read-committed/read-uncommitted, the last row is still locked with an update lock. This is detected by running the JUnit testcase ConcurrencyTest.testUpdatePurgedTuple1 in the DerbyNetClient framework. (NOTE: the bug is revealed by this test, because the network server does a rs.last() as the first operation on a scrollable updatable resultset to count number of rows) What triggers this bug, seems to be the repositioning of the cursor after the underlying all records have been inserted into the hashtable from the source scan. When moving off the result set (to afterLast() or beforeFirst()) no action is done to release the lock of the current row. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1688) ConsistencyToken.hashCode() is not thread safe
[ http://issues.apache.org/jira/browse/DERBY-1688?page=all ] Knut Anders Hatlen closed DERBY-1688. - Fix Version/s: 10.2.0.0 Resolution: Fixed Thanks Dag! I added comments and committed revision 431603. ConsistencyToken.hashCode() is not thread safe -- Key: DERBY-1688 URL: http://issues.apache.org/jira/browse/DERBY-1688 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.2.0.0, 10.2.2.0, 10.3.0.0 Reporter: Knut Anders Hatlen Assigned To: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: derby-1688.diff, derby-1688.stat If ConsistencyToken.hashCode() is run concurrently by different threads, some of the threads may see a partial result instead of the correct hash code. This is not a problem in the current code since all calls to that method are synchronized on a higher level, but it would be good to fix in case the method will be used differently in the future. -- 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-1651) Develop a mechanism to migrate mySQL databases to Derby. Migration tool should include both schema and data migration options.
[ http://issues.apache.org/jira/browse/DERBY-1651?page=all ] Ramin Moazeni updated DERBY-1651: - Attachment: DBMigration.diff Develop a mechanism to migrate mySQL databases to Derby. Migration tool should include both schema and data migration options. -- Key: DERBY-1651 URL: http://issues.apache.org/jira/browse/DERBY-1651 Project: Derby Issue Type: New Feature Components: Tools Environment: All platforms Reporter: Ramin Moazeni Assigned To: Ramin Moazeni Fix For: 10.2.0.0 Attachments: DBMigration.diff, MigrationTool-MySQLtoDerby.zip Develop a mechanism to migration databases created by other database engines to Derby. While my current interest is to migrate mySQL databases to Derby, the tool could be developed in a way to extend this mechanism to allow migration from other database engines in the future. More details of proposed functionality and implementation strategy can be found at: http://wiki.apache.org/db-derby/MysqlDerbyMigration The plan is to develop and submit patches incrementally. First patch supports migration of tables and views from mySQL database to 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
[jira] Commented: (DERBY-1651) Develop a mechanism to migrate mySQL databases to Derby. Migration tool should include both schema and data migration options.
[ http://issues.apache.org/jira/browse/DERBY-1651?page=comments#action_12428140 ] Ramin Moazeni commented on DERBY-1651: -- [8/15/06] This revision added support for procedures, and catalogs to the Database Migration toolkit as well as the User Interface. Currently, migration of tables, views, and catalogs is suported as well as assistance with migration of stored procedures. The patch is attched with this report. Develop a mechanism to migrate mySQL databases to Derby. Migration tool should include both schema and data migration options. -- Key: DERBY-1651 URL: http://issues.apache.org/jira/browse/DERBY-1651 Project: Derby Issue Type: New Feature Components: Tools Environment: All platforms Reporter: Ramin Moazeni Assigned To: Ramin Moazeni Fix For: 10.2.0.0 Attachments: DBMigration.diff, MigrationTool-MySQLtoDerby.zip Develop a mechanism to migration databases created by other database engines to Derby. While my current interest is to migrate mySQL databases to Derby, the tool could be developed in a way to extend this mechanism to allow migration from other database engines in the future. More details of proposed functionality and implementation strategy can be found at: http://wiki.apache.org/db-derby/MysqlDerbyMigration The plan is to develop and submit patches incrementally. First patch supports migration of tables and views from mySQL database to 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: [VOTE] Approve coding conventions for the Derby project
Kathey Marsden wrote: Rick Hillegas wrote: I'm not sure I understand this point. If we recommend a style primer, then I think we're saying that the style is safe and we don't expect committers to flunk a conforming patch for style reasons--provided, of course, that the code is clear. Recommended means safe. I'm just saying it doesn't mean mandatory. I don't think our perspectives are that far apart. I don't think I as a new developer would read the primer pointer as being safe, nor as an existing developer would I read in this the need to make sure that new developers could use that convention safely. I would like to better understand whether your objection to the proposed wording. Is it that it will inhibit your personal style choices or is it that you are concerned that others in the future might interpret it to mean their style choices are limited and that is bad for the project in some way? Kathey I think that there are sound reasons to depart from this style depending on the particular problem your code is solving. Some have been discussed. Others will come up. I am content to deal with them on a case-by-case basis. We can amend our conventions later on. Again, I don't want to bring this vote to a halt. I am changing my vote to -0 Regards, -Rick
[jira] Commented: (DERBY-1694) derbynet/testProperties.java hangs
[ http://issues.apache.org/jira/browse/DERBY-1694?page=comments#action_12428146 ] John H. Embretsen commented on DERBY-1694: -- Thank you for uploading the patch (derby1694diff.txt)! I spent a few minutes studying it, along with the existing code for testProperties.java, and it looks to me that this a clear improvement. I have not run any tests apart from testProperties.java in the DerbyNetClient framework on Solaris 10 x86, Sun JVM 1.5. The only thing I would like to mention is that if this patch gets committed as is, the JavaDoc for the execCmdDumpResults(...) method will (if I have understood the code correctly) no longer match its behavior: /** * Execute the given command and dump the results to standard out * * @param args command and arguments * @param wait true =wait for completion * @exception Exception */ With the patch, if wait == false, results will *not* be dumped to standard out. derbynet/testProperties.java hangs -- Key: DERBY-1694 URL: http://issues.apache.org/jira/browse/DERBY-1694 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.3.0.0 Environment: Windows XP IBM 142 JRE Reporter: Daniel John Debrunner Attachments: derby1694diff.txt The testProperties.execCmd() is used to fork a JVM and not handle its streams. This will cause problems, as indicated by the javadoc for Process. The parent process uses these streams to feed input to and get output from the subprocess. Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the subprocess may cause the subprocess to block, and even deadlock -- 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-1559) when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB
[ http://issues.apache.org/jira/browse/DERBY-1559?page=all ] Tomohito Nakayama updated DERBY-1559: - Attachment: serverMemoryUsage.xls I measured the execution of BlobOutOfMem.java with the patch of DERBY-1559v2.diff. I attach the chart of it. As the chart tolds,memory less than 64m was needed in Network Server to execute BlobOutOfMmem.java with the patch. when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB Key: DERBY-1559 URL: http://issues.apache.org/jira/browse/DERBY-1559 Project: Derby Issue Type: Sub-task Components: Network Server Affects Versions: 10.2.0.0 Reporter: Andreas Korneliussen Assigned To: Andreas Korneliussen Attachments: DERBY-1559.diff, DERBY-1559.stat, DERBY-1559v2.diff, serverMemoryUsage.xls When streaming a BLOB from the Network Client to the Network Server, the Network server currently read all the data from the stream and put it into a byte array. The blob data is then inserted into the DB by using PreparedStatement.setBytes(..) and later PreparedStatement.execute() To avoid OutOfMemoryError if the size of the Blob is than total memory in the VM, we could make the network server create a stream which reads data when doing PreparedStatement.execute(). The DB will then stream the BLOB data directly from the network inputstream into the disk. I intent to make a patch which does this if there is only one EXTDTA object (BLOB) sent from the client in the statement, as it will simplify the implementation. Later this can be improved further to include CLOBs, and possibly to include the cases where there are multiple EXTDTA objects. -- CLOBs are more complex, as there need to be some character encoding. This can be achieved by using a InputStreamReader, and use PreparedStatement.setCharacterStream(..). However the size of the stream is not necessarily the same as the size of the raw binary data, and to do this for CLOBs, I would need the embedded prepared statements to support the new setCharacterStream() overloads in JDBC4 (which do not include a length atribute) -- Multiple EXTDATA objects are also more complex, since one would need to have fully read the previous object ,before it is possible to read the next. -- -- 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-1694) derbynet/testProperties.java hangs
[ http://issues.apache.org/jira/browse/DERBY-1694?page=comments#action_12428151 ] Daniel John Debrunner commented on DERBY-1694: -- Thanks John, I need to fix up the javadoc and coments in the code. However I think that before my patch that wait=true did not dump output to standard out. It called execCmd which just forks the process, it doesn't perform the extra magic that execCmdDumpResults does to display the output. derbynet/testProperties.java hangs -- Key: DERBY-1694 URL: http://issues.apache.org/jira/browse/DERBY-1694 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.3.0.0 Environment: Windows XP IBM 142 JRE Reporter: Daniel John Debrunner Attachments: derby1694diff.txt The testProperties.execCmd() is used to fork a JVM and not handle its streams. This will cause problems, as indicated by the javadoc for Process. The parent process uses these streams to feed input to and get output from the subprocess. Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the subprocess may cause the subprocess to block, and even deadlock -- 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: spec license updated, looks good (was Re: publishing 10.2.1.0 to the Apache mirrors)
Hi Dan, This looks to me like the license distributed with the current Mustang beta, which I used to generate the Derby 10.2.1.0 beta. Regards, -Rick Daniel John Debrunner wrote: Andrew McIntyre wrote: On 8/14/06, Andrew McIntyre [EMAIL PROTECTED] wrote: While the licensing issue is definitely a problem for publishing the beta via the mirrors, it appears that the spec license has been updated. While the licensing issue *was* definitely... Is this the licence that Mustang is being used under in order to build the Derby 10.2 release? http://java.sun.com/javase/6/jdk-6-beta2-license.txt If not, is there a link to the download licence for Mustang? Thanks, Dan.
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (23 issues) Subscriber: derby-dev Key Summary DERBY-1694 derbynet/testProperties.java hangs http://issues.apache.org/jira/browse/DERBY-1694 DERBY-1473 Add cut-off and truncation logic to streaming classes in the embedded driver http://issues.apache.org/jira/browse/DERBY-1473 DERBY-1652 Update trigger updating the same rows as the original update does not throw an exception ERROR 54038: Maximum depth of nested triggers was exceeded as it should http://issues.apache.org/jira/browse/DERBY-1652 DERBY-1655 Document XML functionality for 10.2 http://issues.apache.org/jira/browse/DERBY-1655 DERBY-119 Add ALTER TABLE option to change column from NULL to NOT NULL http://issues.apache.org/jira/browse/DERBY-119 DERBY-1548 Document builtin functions - ACOS, ASIN, ATAN, COS, SIN, TAN, PI, DEGREES, RADIANS, EXP, LN, LOG, LOG10, CEIL, CEILING, FLOOR http://issues.apache.org/jira/browse/DERBY-1548 DERBY-244 with linux, depending on env setting $LANG and console encoding, some i18n tests fail http://issues.apache.org/jira/browse/DERBY-244 DERBY-1057 documentation to address Grant/Revoke (Derby-464) http://issues.apache.org/jira/browse/DERBY-1057 DERBY-1549 Document support for JDBC escape functions: ACOS, ASIN, ATAN, COS, SIN, TAN, PI , DEGREES, RADIANS, EXP, LOG, LOG10, CEILING, FLOOR http://issues.apache.org/jira/browse/DERBY-1549 DERBY-889 with client getTimestamp on a TIME column will print the date 1900-01-01 instead of the current date http://issues.apache.org/jira/browse/DERBY-889 DERBY-415 sysinfo with -cp client option should not print error saying DB2 jar file and driver class are missing http://issues.apache.org/jira/browse/DERBY-415 DERBY-1681 Regression (wrong results): Join predicate can be ignored for left-most child in a chain of nested unions. http://issues.apache.org/jira/browse/DERBY-1681 DERBY-1633 Regression: The fields of views are not being calculated properly since 10.1.2.4 http://issues.apache.org/jira/browse/DERBY-1633 DERBY-1659 Document describe and show tables functionality http://issues.apache.org/jira/browse/DERBY-1659 DERBY-1032 Create new scripts which follow common practice at Apache http://issues.apache.org/jira/browse/DERBY-1032 DERBY-883 Enhance GROUP BY clause to support expressions instead of just column references. http://issues.apache.org/jira/browse/DERBY-883 DERBY-1417 Add new, lengthless overloads to the streaming api http://issues.apache.org/jira/browse/DERBY-1417 DERBY-1643 A revoke execute ... restrict should fail if there are dependent objects on the execute privilege http://issues.apache.org/jira/browse/DERBY-1643 DERBY-1539 A trigger should be dropped when a privilege required by the trigger is revoked. http://issues.apache.org/jira/browse/DERBY-1539 DERBY-815 Prevent unneeded object creation and excessive decoding in parseSQLDTA_work() http://issues.apache.org/jira/browse/DERBY-815 DERBY-646 In-memory backend storage support http://issues.apache.org/jira/browse/DERBY-646 DERBY-801 Allow parallel access to data files. http://issues.apache.org/jira/browse/DERBY-801 DERBY-1194 Derby Server and Administration Guide - Managing the Derby Network Server http://issues.apache.org/jira/browse/DERBY-1194
DERBY-1032: I think patch available can be cleared
I think that the patches attached to this issue have been committed, and there aren't any patches awaiting review. In my opinion, there's no rush to remove the existing frameworks scripts, but it would be nice to see the new scripts appear in the distributions relatively soon so that people could start gaining experience with them from the distributions. thanks, bryan
[jira] Commented: (DERBY-1114) derbynet/testSecMec.java fails intermittently and test exits mysteriously when server is shutdown as part of the testrun.
[
http://issues.apache.org/jira/browse/DERBY-1114?page=comments#action_12428159 ]
Daniel John Debrunner commented on DERBY-1114:
--
The failure I'm seeing is due to this code: line 241
// Wait for the NetworkServer to start.
if (!isServerStarted(networkServer, 60))
System.exit(-1);
The test should not call System.exit(). Instead it should print a failure
message and then break to end the test.
More like.
// Wait for the NetworkServer to start.
if (!isServerStarted(networkServer, 60)) {
System.out.println(FAIL: Server failed to respond
to ping - ending test);
break;
}
The test continued to fail for me, with the above error, but if I increased the
loop count for isServerStarted to 120 from 60 it seems to pass every time.
derbynet/testSecMec.java fails intermittently and test exits mysteriously
when server is shutdown as part of the testrun.
-
Key: DERBY-1114
URL: http://issues.apache.org/jira/browse/DERBY-1114
Project: Derby
Issue Type: Bug
Components: Network Server, Test
Affects Versions: 10.2.0.0
Environment: Java Version:1.4.2_06
Java Vendor: Sun Microsystems Inc.
Java home: /usr/local/lib/j2sdk1.4.2_06/jre
OS name: Linux
OS architecture: i386
OS version: 2.4.21-27.0.2.ELsmp
Reporter: Sunitha Kambhampati
Assigned To: Bryan Pendleton
Priority: Minor
Attachments: Derby1114.diff.txt, Stdout.java,
testSecMec_test_output.zip
The test derbynet/testSecMec.java fails intermittently in a strange way that
the test actually exits before finishing the full test.
This issue was noticed by Bryan when he ran derbyall with the derby-1080 fix.
Some discussion and analysis that has been done is in Derby-1080. Please read
comments in DERBY-1080. Some main links in
http://issues.apache.org/jira/browse/DERBY-1080#action_12370260
http://issues.apache.org/jira/browse/DERBY-1080#action_12370374
In short: the test does some switching of System.out and System.err streams
before calling networkserver.shutdown. This code was added to this test as
part of fix for derby-273. for some reason, the networkserver.shutdown call
makes the test to exit. One theory is that the network server.shutdown is
causing the standard out streams to close and thus the test exits.
-- Need to investigate what is the cause for this intermittent failure and
how/why networkserver.shutdown is closing the stream or making the test to
exit prematurely.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Regression Test Failure! - TinderBox_Derby 431593 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 431593/2006-08-15 14:52:29 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 2677675 2 155.35% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-431593.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/431593.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/431593.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Commented: (DERBY-1694) derbynet/testProperties.java hangs
[ http://issues.apache.org/jira/browse/DERBY-1694?page=comments#action_12428160 ] John H. Embretsen commented on DERBY-1694: -- Yes, that is true. I see now that the JavaDoc must have been wrong before applying the patch as well, since there was no parameter to execCmdDumpResults called wait, although there is a JavaDoc @param tag saying so. By the way, can someone help me understand why derbynet/testProperties_derby.properties sets some of the properties multiple times? It seems that the patch for DERBY-706 only set them once, but that something went wrong when applying/committing the patch... (?) derbynet/testProperties.java hangs -- Key: DERBY-1694 URL: http://issues.apache.org/jira/browse/DERBY-1694 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.3.0.0 Environment: Windows XP IBM 142 JRE Reporter: Daniel John Debrunner Attachments: derby1694diff.txt The testProperties.execCmd() is used to fork a JVM and not handle its streams. This will cause problems, as indicated by the javadoc for Process. The parent process uses these streams to feed input to and get output from the subprocess. Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the subprocess may cause the subprocess to block, and even deadlock -- 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-1652) Update trigger updating the same rows as the original update does not throw an exception ERROR 54038: Maximum depth of nested triggers was exceeded as it should
[ http://issues.apache.org/jira/browse/DERBY-1652?page=all ] Mike Matrigali updated DERBY-1652: -- Derby Info: [Patch Available, Existing Application Impact, Release Note Needed] (was: [Release Note Needed, Patch Available, Existing Application Impact]) I am looking at committing the trunk submitted diff, assuming there is no objection. It seems like Dag's comment can be handled as a separate item. To this end I ran all the tests on XP, sun jdk1.4.2 and got 3 diffs: derbyall/derbynetmats/DerbyNet/jdbcapi/blobclob4BLOB.diff (known issue showing up in the tinderbox tests) derbyall/upgrade/Upgrade_10_1_10_2.diff (known issue showing up in the tinderbox tests) and the following I need to investigate: *** Start: _Suite jdk1.4.2_07 DerbyNetClient derbynetmats:jdbcapi 2006-08-14 19: 57:40 *** 0 add ..E...E. There were 2 errors: 1) testUpdateUpdatedTupleScrollUpdateRow(org.apache.derbyTesting.functionTests .tests.jdbcapi.URCoveringIndexTest)java.lang.OutOfMemoryError 2) testNextOnLastRowForwardOnly(org.apache.derbyTesting.functionTests.tests.jd bcapi.ScrollResultSetTest)java.lang.OutOfMemoryError FAILURES!!! Tests run: 817, Failures: 0, Errors: 2 Test Failed. *** End: _Suite jdk1.4.2_07 DerbyNetClient derbynetmats:jdbcapi 2006-08-14 20: 01:56 *** Update trigger updating the same rows as the original update does not throw an exception ERROR 54038: Maximum depth of nested triggers was exceeded as it should --- Key: DERBY-1652 URL: http://issues.apache.org/jira/browse/DERBY-1652 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.0.2.0, 10.2.0.0, 10.1.3.1 Reporter: Kathey Marsden Assigned To: Yip Ng Fix For: 10.2.0.0, 10.1.3.2 Attachments: derby1652-10.1.3-diff.txt, derby1652-10.1.3-stat.txt, derby1652-trunk-diff01.txt, derby1652-trunk-stat01.txt Execution of an update trigger that updates the same row as the original update will recurse forever and exceed the maximum nesting level of 16 so should throw the exception: ERROR 54038: Maximum depth of nested triggers was exceeded However, it does not always throw the exception. For example: CREATE TABLE TEST ( TESTID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1), INFO INTEGER NOT NULL, TIMESTAMP TIMESTAMP NOT NULL DEFAULT '1980-01-01-00.00.00.00' ); CREATE TRIGGER UPDATE_TEST AFTER UPDATE ON TEST REFERENCING OLD AS OLD FOR EACH ROW MODE DB2SQL UPDATE TEST SET TIMESTAMP = CURRENT_TIMESTAMP WHERE TESTID = OLD.TESTID; INSERT INTO TEST (INFO) VALUES (1), (2), (3); UPDATE TEST SET INFO = 1 WHERE TESTID = 2; Does not throw an exception: However, If the derby jars are updated to a new version, the correct exception is thrown. Replace derby jars with new version Execute the following in ij: UPDATE TEST SET INFO = 1 WHERE TESTID = 2; ERROR 54038: Maximum depth of nested triggers was exceeded. Note: This issue stemmed from the Invalid issue, DERBY-1603, because a user hit the exception after upgrade and thought the exception after upgrade, not the lack of exception before upgrade was the problem. This may be a common user error, so we need a release note to help mitigate the issue.I will add one shortly after confirming the correct trigger syntax. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1691) jdbcapi/blobclob4BLOB.java fails under DerbyNet framework with JCC 2.6
[ http://issues.apache.org/jira/browse/DERBY-1691?page=all ] Mike Matrigali updated DERBY-1691: -- Component/s: Regression Test Failure jdbcapi/blobclob4BLOB.java fails under DerbyNet framework with JCC 2.6 -- Key: DERBY-1691 URL: http://issues.apache.org/jira/browse/DERBY-1691 Project: Derby Issue Type: Bug Components: Test, Regression Test Failure Affects Versions: 10.2.0.0 Environment: Linux 2.6.9-5.ELsmp Sun jdk 1.5.0_07-b03 Reporter: Rajesh Kartha Fix For: 10.2.0.0 With JCC 2.6, the jdbcapi/blobclob4BLOB.java fails. The diff did not show anything alarming, so I am guessing it may be a master update. The test passed fine with DerbyClient *** Start: blobclob4BLOB jdk1.5.0_06 DerbyNet derbynetmats:jdbcapi 2006-08-11 23:29:48 *** 466a467,474 EXPECTED SQLSTATE(22018): Invalid character string format for type INTEGER. end clobTest54 START: clobTest6 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 FAIL -- unexpected exception:java.lang.StringIndexOutOfBoundsException: String index out of range: -1 468,475d475 EXPECTED SQLSTATE(22018): Invalid character string format for type INTEGER. end clobTest54 START: clobTest6 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 FAIL -- unexpected exception:java.lang.StringIndexOutOfBoundsException: String index out of range: -1 775a776,782 blobTest54 finished START: blobTest6 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 FAIL -- unexpected exception:java.lang.NegativeArraySizeException 777,783d783 blobTest54 finished START: blobTest6 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 FAIL -- unexpected exception:java.lang.NegativeArraySizeException 789 del com.ibm.db2.jcc.c.SqlException: Operation 'CREATE TRIGGER' cannot be performed on object 'TESTBLOB' because there is an open ResultSet dependent on that object. 789a789 com.ibm.db2.jcc.a.SqlException: Operation 'CREATE TRIGGER' cannot be performed on object 'TESTBLOB' because there is an open ResultSet dependent on that object. Test Failed. *** End: blobclob4BLOB jdk1.5.0_06 DerbyNet derbynetmats:jdbcapi 2006-08-11 23:30:46 *** -- 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-1692) Client driver does not use the query timeout value set using Statement.setQueryTimeout() for subsequent executions using the same statement object
[ http://issues.apache.org/jira/browse/DERBY-1692?page=comments#action_12428163 ] Deepa Remesh commented on DERBY-1692: - This happens only with Statement class. It does not occur with PreparedStatement or CallableStatement objects. Client driver does not use the query timeout value set using Statement.setQueryTimeout() for subsequent executions using the same statement object -- Key: DERBY-1692 URL: http://issues.apache.org/jira/browse/DERBY-1692 Project: Derby Issue Type: Bug Components: Network Client, Network Server Affects Versions: 10.2.0.0, 10.3.0.0 Reporter: Deepa Remesh Attachments: TestQueryTimeout.java I will attach a repro with more details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1057) documentation to address Grant/Revoke (Derby-464)
[ http://issues.apache.org/jira/browse/DERBY-1057?page=comments#action_12428164 ] Mamta A. Satoor commented on DERBY-1057: Laura, I went through the 2 examples about PUBLIC and user-level privileges. One change is required to the 2nd example- make the privilege available at user-level after the object is created, And show that when the PUBLIC level privilege is revoked, Derby currently does not use available user-level privilege. In addition, in both the examples, at the end, when we say the object is dropped, we should say that how the privilege being revoked is available at a different level but is not used by Derby. Here is my suggestion for the 2 examples Example 1 User zhi creates table t1 and grants SELECT privileges to user harry on table t1. User zhi grants SELECT privileges to PUBLIC on table t1. User harry creates view v1 with the statement SELECT * from zhi.t1. The view depends on the user-level privilege that user harry has on t1. Subsequently, user zhi revokes SELECT privileges from user harry on table t1. As a result, the view harry.v1 is dropped even though user harry has SELECT privilege on table t1 at PUBLIC level,. Example 2 User anita creates table t1 and grants SELECT privileges to PUBLIC. User harry creates view v1 with the statement SELECT * from anita.t1. The view depends on the PUBLIC level privilege that user harry has on t1 since user harry does not have user-level privileges on table t1. Later, user anita grants SELECT privilege to user harry on table t1. Subsequently, user anita revokes SELECT privileges from PUBLIC on table t1. As a result, the view harry.v1 is dropped even though user harry has SELECT privilege on table t1 at user-level. documentation to address Grant/Revoke (Derby-464) - Key: DERBY-1057 URL: http://issues.apache.org/jira/browse/DERBY-1057 Project: Derby Issue Type: Sub-task Components: Documentation Affects Versions: 10.0.2.0 Reporter: Eric Radzinski Assigned To: Laura Stewart Fix For: 10.2.0.0 Attachments: derby1057_devguide.diff, derby1057_devguide3.diff, derby1057_devguide4.ddiff, derby1057_devguide_html.zip, derby1057_devguide_html3.zip, derby1057_devguide_html4.zip, derby1057_ref.diff, derby1057_ref3.diff, derby1057_ref4.diff, derby1057_ref_html.zip, derby1057_ref_html4.zip, derby1057_tuning3.diff, derby1057_tuning4.diff, derby1057_tuning_html.zip, derby1058_ref_html3.zip, devguide_html2.zip, ref_html2.zip, rtunpropersqlauth.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-1032) Create new scripts which follow common practice at Apache
[ http://issues.apache.org/jira/browse/DERBY-1032?page=all ] Andrew McIntyre updated DERBY-1032: --- Attachment: derby-1032-addtodist2.diff Attaching a second version of this patch that also removes the frameworks scripts from the snapshots. Create new scripts which follow common practice at Apache - Key: DERBY-1032 URL: http://issues.apache.org/jira/browse/DERBY-1032 Project: Derby Issue Type: Improvement Components: Demos/Scripts Affects Versions: 10.2.0.0 Reporter: Andrew McIntyre Assigned To: Andrew McIntyre Priority: Minor Fix For: 10.2.0.0 Attachments: derby-1032-addtodist.diff, derby-1032-addtodist2.diff, derby-1032-bin-sh.tgz, derby-1032-v1.diff, derby-1032-v2.diff Scripts for Derby should be written to follow common practice at Apache. This means locating them in a bin directory, and self configuring from the minimum amount of information necessary: installation location and in our case, the location of Java, from the variables DERBY_HOME and JAVA_HOME respectively. If these variables are not set, we should report this to the user. Good examples are available in Ant, Forrest, and Maven, and much of the same setup code can be reused from those projects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: DERBY-1032
On 8/15/06, Bryan Pendleton [EMAIL PROTECTED] wrote: I think that the patches attached to this issue have been committed, and there aren't any patches awaiting review. In my opinion, there's no rush to remove the existing frameworks scripts, but it would be nice to see the new scripts appear in the distributions relatively soon so that people could start gaining experience with them from the distributions. Hi Bryan, Thanks for noticing that. So, I've added a new patch to DERBY-1032 that adds the new scripts to the -bin distribution and removes them from the snapshots. I agree that the frameworks can be deprecated separately and that there's no rush to remove them. I'm curious to hear if anyone has any concerns with either adding the scripts to -bin or removing them from the snapshots. If I hear no objections, I'll commit the -addtodist2 patch tomorrow. andrew
[jira] Commented: (DERBY-1697) Upgrade_10_1_10_2 test fails in tinderbox run in trunk
[ http://issues.apache.org/jira/browse/DERBY-1697?page=comments#action_12428168 ] Andrew McIntyre commented on DERBY-1697: Is this a duplicate of DERBY-1689? Upgrade_10_1_10_2 test fails in tinderbox run in trunk -- Key: DERBY-1697 URL: http://issues.apache.org/jira/browse/DERBY-1697 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.3.0.0 Environment: Generating report for RunSuite derbyall null null null true -- Java Information -- Java Version:1.4.2_07 Java Vendor: Sun Microsystems Inc. Java home: c:\p4\m1\jdk142\jre Java classpath: c:/p4/m1/classes;c:/p4/m1/tools/java/jdbctests.zip;c:/p4/m1/too ls/java/jakarta-oro-2.0.8.jar;c:/p4/m1/tools/java/jgl3.1.0.jar;c:/p4/m1/tools/ja va/jndi/providerutil.jar;c:/p4/m1/tools/java/jndi/ldap.jar;c:/p4/m1/tools/java/j ndi/jndi.jar;c:/p4/m1/tools/java/RmiJdbc.jar;c:/p4/m1/drda/jcc/2.4/db2jcc.jar;c: /p4/m1/drda/jcc/2.4/db2jcc_license_c.jar;c:/p4/m1/tools/java/jnl1.0F.zip;c:/p4/m 1/tools/java/junit.jar;c:/p4/m1/tools/java/servlet-2_2b.jar;c:/p4/m1/tools/java/ xslt4j-2_5_0/xercesImpl.jar;c:/p4/m1/tools/java/xslt4j-2_5_0/xml-apis.jar;c:/p4/ m1/tools/java/xslt4j-2_5_0/xalan.jar OS name: Windows XP OS architecture: x86 OS version: 5.1 Java user name: mikem Java user home: C:\Documents and Settings\Administrator Java user dir: C:\p4\m1\systest\out\derby java.specification.name: Java Platform API Specification java.specification.version: 1.4 - Derby Information JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 [C:\p4\m1\classes] 10.3.0.0 alpha - (1) [C:\p4\m1\drda\jcc\2.4\db2jcc.jar] 2.4 - (17) [C:\p4\m1\drda\jcc\2.4\db2jcc_license_c.jar] 2.4 - (17) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [de_DE] version: 10.3.0.0 alpha - (1) Found support for locale: [es] version: 10.3.0.0 alpha - (1) Found support for locale: [fr] version: 10.3.0.0 alpha - (1) Found support for locale: [it] version: 10.3.0.0 alpha - (1) Found support for locale: [ja_JP] version: 10.3.0.0 alpha - (1) Found support for locale: [ko_KR] version: 10.3.0.0 alpha - (1) Found support for locale: [pt_BR] version: 10.3.0.0 alpha - (1) Found support for locale: [zh_CN] version: 10.3.0.0 alpha - (1) Found support for locale: [zh_TW] version: 10.3.0.0 alpha - (1) -- Test environment information: COMMAND LINE STYLE: jdk13 TEST CANONS: master -- -- Reporter: Mike Matrigali *** Start: Upgrade_10_1_10_2 jdk1.5.0_04 derbyall:upgrade 2006-08-15 18:01:36 *** 708 del complete caseVersionCheck - passed true 708a708 complete caseVersionCheck - passed false 1463 del END - PASS - phase SOFT UPGRADE 1463a1463 END - FAIL - phase SOFT UPGRADE 2173 del complete caseVersionCheck - passed true 2173a2173 complete caseVersionCheck - passed false 2955 del END - PASS - phase UPGRADE 2955a2955 END - FAIL - phase UPGRADE Test Failed. *** End: Upgrade_10_1_10_2 jdk1.5.0_04 derbyall:upgrade 2006-08-15 18:02:14 *** -- 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-1689) Remove Upgrade_10_1_10_2 test from 10.3 and add new upgrade tests for 10.3
[ http://issues.apache.org/jira/browse/DERBY-1689?page=all ] Deepa Remesh updated DERBY-1689: Component/s: Regression Test Failure Remove Upgrade_10_1_10_2 test from 10.3 and add new upgrade tests for 10.3 -- Key: DERBY-1689 URL: http://issues.apache.org/jira/browse/DERBY-1689 Project: Derby Issue Type: Task Components: Test, Regression Test Failure Affects Versions: 10.3.0.0 Reporter: Deepa Remesh Priority: Minor Fix For: 10.3.0.0 The current upgrade test Upgrade_10_1_10_2 tests upgrade from 10.1 to 10.2. This test should continue to run in 10.2 branch. It is failing in the new trunk (10.3) because the test internally checks the versions. To resolve this failure, we should remove this test from running in new trunk and then create new upgrade tests to test new upgrade scenarios: * 10.1 to 10.3 * 10.2 to 10.3 Upgrade test uses the UpgradeTester class which contains the test for various upgrade scenarios. To test any old/new release upgrade combination, we can create a new test which uses this class and pass in the old and new versions to the class. Any new upgrade scenarios for new features can be added to UpgradeTester (e.g, test for 10.2 feature grant/revoke was added to UpgradeTester). -- 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-1693) Out of Memory Error with derby.language.logStatementText=true
[ http://issues.apache.org/jira/browse/DERBY-1693?page=all ] Mike Matrigali updated DERBY-1693: -- I agree, my guess is that we are trying to print out the whole blob/clob in the log statement text. This is very unlikely what the user wants. And in the current architecture anytime you try to do 2 different things with streamed blob/clob then the blob/clob is going to get instantiated in memory. So for instance on an insert we can stream the blob to the store, but if we need to print it to the log first we are going to call toString and end up with it in memory (of course you could stream to disk and back but doesn't seem worth it for logstatement text). My question is what should log statement text do. The easiest is just not print values for the blob/clob. Is that ok? 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.0.0 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 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
Re: publishing 10.2.1.0 to the Apache mirrors
Thanks, Jean. I agree. -Rick Jean T. Anderson wrote: Rick Hillegas wrote: Thanks, Jean. I will stop putting effort into this one. Even with the jdbc 4.0 license issue resolved, you mentioned other serious defects, which makes me think that holding off on this one would be wise. You noted that the next distribution can be a serious release candidate -- maybe *that* would be the one to put on the mirrors. Voting to put a beta on the mirrors doesn't seem like the best use of the community's time to me unless it is a serious candidate. But that's just my opinion -jean Regards, -Rick Jean T. Anderson wrote: Jean T. Anderson wrote: Rick Hillegas wrote: ... I don't know. It was suggested last week that we publish the beta to the mirrors to broaden its exposure. The intention wasn't to claim that it was GA-ready. I'm trying to figure out what is entailed in publishing a beta to the Apache mirrors. Has this been done before? Maybe I should copy the distribution to svn.apache.org rather than www.apache.org? I'm muddled by the description at http://www.apache.org/dev/mirrors.html. anything that is put on the asf mirrors must be voted on, approved by the pmc, signed etc. The asf doesn't require that a distribution be GA ready. Rick, earlier in another thread [1] you wrote: I don't think that this beta can become a release. It has some serious defects, including the licensing issues. However, those defects do not prevent users from testing the completed features. I'm hoping we will get significant feedback during this beta period so that the next distribution can be a serious release candidate No, this should not go up on the mirrors. -jean [1] http://mail-archives.apache.org/mod_mbox/db-derby-dev/200608.mbox/[EMAIL PROTECTED]
[jira] Commented: (DERBY-1057) documentation to address Grant/Revoke (Derby-464)
[ http://issues.apache.org/jira/browse/DERBY-1057?page=comments#action_12428170 ] Satheesh Bandaram commented on DERBY-1057: -- I think GRANT/REVOKE documentation to reference guide and developer guide can be committed, following several reviews by myself, mamta and Dan. I would also recommend second review after the commit, looking at the whole documentation, not just the changes, considering the scope of authorization impact. I will also be doing this second round review and invite others, like Francois, Mamta, Dan or anyone else. Would appreciate if someone can commit patches Derby1057_ref4.diff and Derby1057_devguide4.diff. documentation to address Grant/Revoke (Derby-464) - Key: DERBY-1057 URL: http://issues.apache.org/jira/browse/DERBY-1057 Project: Derby Issue Type: Sub-task Components: Documentation Affects Versions: 10.0.2.0 Reporter: Eric Radzinski Assigned To: Laura Stewart Fix For: 10.2.0.0 Attachments: derby1057_devguide.diff, derby1057_devguide3.diff, derby1057_devguide4.ddiff, derby1057_devguide_html.zip, derby1057_devguide_html3.zip, derby1057_devguide_html4.zip, derby1057_ref.diff, derby1057_ref3.diff, derby1057_ref4.diff, derby1057_ref_html.zip, derby1057_ref_html4.zip, derby1057_tuning3.diff, derby1057_tuning4.diff, derby1057_tuning_html.zip, derby1058_ref_html3.zip, devguide_html2.zip, ref_html2.zip, rtunpropersqlauth.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: [jira] Commented: (DERBY-1057) documentation to address Grant/Revoke (Derby-464)
Satheesh Bandaram (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1057?page=comments#action_12428170 ] Satheesh Bandaram commented on DERBY-1057: -- I think GRANT/REVOKE documentation to reference guide and developer guide can be committed, following several reviews by myself, mamta and Dan. I would also recommend second review after the commit, looking at the whole documentation, not just the changes, considering the scope of authorization impact. I will also be doing this second round review and invite others, like Francois, Mamta, Dan or anyone else. Would appreciate if someone can commit patches Derby1057_ref4.diff and Derby1057_devguide4.diff. I'll go ahead and commit. It looks to me that there are some outstanding comments by Mamta that can be rolled into the next pass. -jean
[jira] Closed: (DERBY-1697) Upgrade_10_1_10_2 test fails in tinderbox run in trunk
[ http://issues.apache.org/jira/browse/DERBY-1697?page=all ] Deepa Remesh closed DERBY-1697. --- Resolution: Duplicate I have added Regression Test Failure component to DERBY-1689. Marking this as duplicate. Upgrade_10_1_10_2 test fails in tinderbox run in trunk -- Key: DERBY-1697 URL: http://issues.apache.org/jira/browse/DERBY-1697 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.3.0.0 Environment: Generating report for RunSuite derbyall null null null true -- Java Information -- Java Version:1.4.2_07 Java Vendor: Sun Microsystems Inc. Java home: c:\p4\m1\jdk142\jre Java classpath: c:/p4/m1/classes;c:/p4/m1/tools/java/jdbctests.zip;c:/p4/m1/too ls/java/jakarta-oro-2.0.8.jar;c:/p4/m1/tools/java/jgl3.1.0.jar;c:/p4/m1/tools/ja va/jndi/providerutil.jar;c:/p4/m1/tools/java/jndi/ldap.jar;c:/p4/m1/tools/java/j ndi/jndi.jar;c:/p4/m1/tools/java/RmiJdbc.jar;c:/p4/m1/drda/jcc/2.4/db2jcc.jar;c: /p4/m1/drda/jcc/2.4/db2jcc_license_c.jar;c:/p4/m1/tools/java/jnl1.0F.zip;c:/p4/m 1/tools/java/junit.jar;c:/p4/m1/tools/java/servlet-2_2b.jar;c:/p4/m1/tools/java/ xslt4j-2_5_0/xercesImpl.jar;c:/p4/m1/tools/java/xslt4j-2_5_0/xml-apis.jar;c:/p4/ m1/tools/java/xslt4j-2_5_0/xalan.jar OS name: Windows XP OS architecture: x86 OS version: 5.1 Java user name: mikem Java user home: C:\Documents and Settings\Administrator Java user dir: C:\p4\m1\systest\out\derby java.specification.name: Java Platform API Specification java.specification.version: 1.4 - Derby Information JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 [C:\p4\m1\classes] 10.3.0.0 alpha - (1) [C:\p4\m1\drda\jcc\2.4\db2jcc.jar] 2.4 - (17) [C:\p4\m1\drda\jcc\2.4\db2jcc_license_c.jar] 2.4 - (17) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [de_DE] version: 10.3.0.0 alpha - (1) Found support for locale: [es] version: 10.3.0.0 alpha - (1) Found support for locale: [fr] version: 10.3.0.0 alpha - (1) Found support for locale: [it] version: 10.3.0.0 alpha - (1) Found support for locale: [ja_JP] version: 10.3.0.0 alpha - (1) Found support for locale: [ko_KR] version: 10.3.0.0 alpha - (1) Found support for locale: [pt_BR] version: 10.3.0.0 alpha - (1) Found support for locale: [zh_CN] version: 10.3.0.0 alpha - (1) Found support for locale: [zh_TW] version: 10.3.0.0 alpha - (1) -- Test environment information: COMMAND LINE STYLE: jdk13 TEST CANONS: master -- -- Reporter: Mike Matrigali *** Start: Upgrade_10_1_10_2 jdk1.5.0_04 derbyall:upgrade 2006-08-15 18:01:36 *** 708 del complete caseVersionCheck - passed true 708a708 complete caseVersionCheck - passed false 1463 del END - PASS - phase SOFT UPGRADE 1463a1463 END - FAIL - phase SOFT UPGRADE 2173 del complete caseVersionCheck - passed true 2173a2173 complete caseVersionCheck - passed false 2955 del END - PASS - phase UPGRADE 2955a2955 END - FAIL - phase UPGRADE Test Failed. *** End: Upgrade_10_1_10_2 jdk1.5.0_04 derbyall:upgrade 2006-08-15 18:02:14 *** -- 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-1694) derbynet/testProperties.java hangs
[ http://issues.apache.org/jira/browse/DERBY-1694?page=all ] Daniel John Debrunner updated DERBY-1694: - Component/s: Regression Test Failure (was: Test) derbynet/testProperties.java hangs -- Key: DERBY-1694 URL: http://issues.apache.org/jira/browse/DERBY-1694 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.3.0.0 Environment: Windows XP IBM 142 JRE Reporter: Daniel John Debrunner Attachments: derby1694diff.txt The testProperties.execCmd() is used to fork a JVM and not handle its streams. This will cause problems, as indicated by the javadoc for Process. The parent process uses these streams to feed input to and get output from the subprocess. Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the subprocess may cause the subprocess to block, and even deadlock -- 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-1639) Include early-draft notice required by JDBC 4 spec license in NOTICES, release notes and documentation
[ http://issues.apache.org/jira/browse/DERBY-1639?page=all ] Andrew McIntyre resolved DERBY-1639. Resolution: Invalid Derby Info: (was: [Release Note Needed]) Marking this as invalid and removing the release note needed flag, since the language that would have required this notice in the JDBC 4 spec license has been removed. Include early-draft notice required by JDBC 4 spec license in NOTICES, release notes and documentation -- Key: DERBY-1639 URL: http://issues.apache.org/jira/browse/DERBY-1639 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.0.0 Reporter: Andrew McIntyre Assigned To: Rick Hillegas Fix For: 10.2.0.0 Attachments: derby-1639-notice_v01.diff, derby-1639-notice_v02.diff from the license: 3. Distribute applications written to the Specification to third parties for their testing and evaluation use, provided that any such application includes the following notice: This is an application written to interoperate with an early-draft specification developed under the Java Community Process (JCP) and is made available for testing and evaluation purposes only. The code is not compatible with any specification of the JCP. This notice needs to be included in the NOTICES file, and should also be used to frame discussion of JDBC 4.0 features in the release notes and documentation. Here is a RELEASE NOTE for inclusion with this issue. I am editting this note into the Description field so that we can amend it if necessary: - RELEASE NOTE PROBLEM: Derby 10.2 exposes an implementation of an early draft version of the JDBC4 specification. SYMPTOM: This issue only affects you if you are running the Derby network client or embedded server on Java SE 6. This issue does not affect you if you are running Derby on J2SE 1.3, 1.4, or 1.5. When run on Java SE 6, Derby's network client and embedded server expose JDBC implementations which do not conform to an approved, final version of the JDBC specification. Instead, these implementations adhere to an early-draft version of the JDBC4 specification. Please note the following: This is an application written to interoperate with an early-draft specification developed under the Java Community Process (JCP) and is made available for testing and evaluation purposes only. The code is not compatible with any specification of the JCP. SOLUTION: A follow-on release will expose JDBC4 implementations conforming to the final draft of the JDBC4 specification. WORKAROUND: If you do not want to use experimental, early-draft JDBC4 interfaces, run Derby on J2SE 1.3, 1.4, or 1.5 or on J2ME/CDC/Foundation 1.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1639) Include early-draft notice required by JDBC 4 spec license in NOTICES, release notes and documentation
[ http://issues.apache.org/jira/browse/DERBY-1639?page=all ] Andrew McIntyre closed DERBY-1639. -- Include early-draft notice required by JDBC 4 spec license in NOTICES, release notes and documentation -- Key: DERBY-1639 URL: http://issues.apache.org/jira/browse/DERBY-1639 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.0.0 Reporter: Andrew McIntyre Assigned To: Rick Hillegas Fix For: 10.2.0.0 Attachments: derby-1639-notice_v01.diff, derby-1639-notice_v02.diff from the license: 3. Distribute applications written to the Specification to third parties for their testing and evaluation use, provided that any such application includes the following notice: This is an application written to interoperate with an early-draft specification developed under the Java Community Process (JCP) and is made available for testing and evaluation purposes only. The code is not compatible with any specification of the JCP. This notice needs to be included in the NOTICES file, and should also be used to frame discussion of JDBC 4.0 features in the release notes and documentation. Here is a RELEASE NOTE for inclusion with this issue. I am editting this note into the Description field so that we can amend it if necessary: - RELEASE NOTE PROBLEM: Derby 10.2 exposes an implementation of an early draft version of the JDBC4 specification. SYMPTOM: This issue only affects you if you are running the Derby network client or embedded server on Java SE 6. This issue does not affect you if you are running Derby on J2SE 1.3, 1.4, or 1.5. When run on Java SE 6, Derby's network client and embedded server expose JDBC implementations which do not conform to an approved, final version of the JDBC specification. Instead, these implementations adhere to an early-draft version of the JDBC4 specification. Please note the following: This is an application written to interoperate with an early-draft specification developed under the Java Community Process (JCP) and is made available for testing and evaluation purposes only. The code is not compatible with any specification of the JCP. SOLUTION: A follow-on release will expose JDBC4 implementations conforming to the final draft of the JDBC4 specification. WORKAROUND: If you do not want to use experimental, early-draft JDBC4 interfaces, run Derby on J2SE 1.3, 1.4, or 1.5 or on J2ME/CDC/Foundation 1.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Approve coding conventions for the Derby project
Rick Hillegas wrote: We can amend our conventions later on. Again, I don't want to bring this vote to a halt. I am changing my vote to -0 Thanks Rick. I appreciate your willingness to defer revisions to another round. I think there were great potential improvements that came out of this conversation and vote. I especially like Bernt's suggestion that we add an amendment to - use common sense and move the statement about no whitespace or reformatting diffs in patches up to the ammendments.Hopefully this type of change will be a much easier sell and can happen without a big formal vote. Thanks again for your patience. Kathey
[jira] Commented: (DERBY-1693) Out of Memory Error with derby.language.logStatementText=true
[ http://issues.apache.org/jira/browse/DERBY-1693?page=comments#action_12428183 ] Kristian Waagan commented on DERBY-1693: When a very similar problem was fixed in the network server code, I think the length of the LOB was included. Maybe something like 'BLOB(2048)'. This looks useful to me, but we may not always know the length (for instance when a BLOB with an associated stream is used as input). For these, I guess marking the length as unknown is okay. 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.0.0 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 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
some minor doc warnings on the truk...
[javadoc] C:\nightlies\main\src\opensource\java\engine\org\apache\derby\iapi\types\XML.java:262: warning - Tag @see: can't find setFrom org.apache.derby.iapi.types.DataValueDescriptor [javadoc] C:\nightlies\main\src\opensource\java\engine\org\apache\derby\iapi\types\XML.java:163: warning - @param argument qualXType is not a parameter name. [javadoc] C:\nightlies\main\src\opensource\java\client\org\apache\derby\client\net\NetConnectionReply.java:511: warning - @param argument connection is not a parameter name. [javadoc] C:\nightlies\main\src\opensource\java\client\org\apache\derby\client\net\NetConnectionReply.java:524: warning - @param argument connection is not a parameter name. [javadoc] 4 warnings Thanks -suresh
Re: [jira] Closed: (DERBY-1697) Upgrade_10_1_10_2 test fails in tinderbox run in trunk
Thanks, I should have done a better search. I just did a search in the regression test component and didn't see it. I agree this one should be closed, 1689 has a much better description of the problem. Deepa Remesh (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1697?page=all ] Deepa Remesh closed DERBY-1697. --- Resolution: Duplicate I have added Regression Test Failure component to DERBY-1689. Marking this as duplicate. Upgrade_10_1_10_2 test fails in tinderbox run in trunk -- Key: DERBY-1697 URL: http://issues.apache.org/jira/browse/DERBY-1697 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.3.0.0 Environment: Generating report for RunSuite derbyall null null null true -- Java Information -- Java Version:1.4.2_07 Java Vendor: Sun Microsystems Inc. Java home: c:\p4\m1\jdk142\jre Java classpath: c:/p4/m1/classes;c:/p4/m1/tools/java/jdbctests.zip;c:/p4/m1/too ls/java/jakarta-oro-2.0.8.jar;c:/p4/m1/tools/java/jgl3.1.0.jar;c:/p4/m1/tools/ja va/jndi/providerutil.jar;c:/p4/m1/tools/java/jndi/ldap.jar;c:/p4/m1/tools/java/j ndi/jndi.jar;c:/p4/m1/tools/java/RmiJdbc.jar;c:/p4/m1/drda/jcc/2.4/db2jcc.jar;c: /p4/m1/drda/jcc/2.4/db2jcc_license_c.jar;c:/p4/m1/tools/java/jnl1.0F.zip;c:/p4/m 1/tools/java/junit.jar;c:/p4/m1/tools/java/servlet-2_2b.jar;c:/p4/m1/tools/java/ xslt4j-2_5_0/xercesImpl.jar;c:/p4/m1/tools/java/xslt4j-2_5_0/xml-apis.jar;c:/p4/ m1/tools/java/xslt4j-2_5_0/xalan.jar OS name: Windows XP OS architecture: x86 OS version: 5.1 Java user name: mikem Java user home: C:\Documents and Settings\Administrator Java user dir: C:\p4\m1\systest\out\derby java.specification.name: Java Platform API Specification java.specification.version: 1.4 - Derby Information JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 [C:\p4\m1\classes] 10.3.0.0 alpha - (1) [C:\p4\m1\drda\jcc\2.4\db2jcc.jar] 2.4 - (17) [C:\p4\m1\drda\jcc\2.4\db2jcc_license_c.jar] 2.4 - (17) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [de_DE] version: 10.3.0.0 alpha - (1) Found support for locale: [es] version: 10.3.0.0 alpha - (1) Found support for locale: [fr] version: 10.3.0.0 alpha - (1) Found support for locale: [it] version: 10.3.0.0 alpha - (1) Found support for locale: [ja_JP] version: 10.3.0.0 alpha - (1) Found support for locale: [ko_KR] version: 10.3.0.0 alpha - (1) Found support for locale: [pt_BR] version: 10.3.0.0 alpha - (1) Found support for locale: [zh_CN] version: 10.3.0.0 alpha - (1) Found support for locale: [zh_TW] version: 10.3.0.0 alpha - (1) -- Test environment information: COMMAND LINE STYLE: jdk13 TEST CANONS: master -- -- Reporter: Mike Matrigali *** Start: Upgrade_10_1_10_2 jdk1.5.0_04 derbyall:upgrade 2006-08-15 18:01:36 *** 708 del complete caseVersionCheck - passed true 708a708 complete caseVersionCheck - passed false 1463 del END - PASS - phase SOFT UPGRADE 1463a1463 END - FAIL - phase SOFT UPGRADE 2173 del complete caseVersionCheck - passed true 2173a2173 complete caseVersionCheck - passed false 2955 del END - PASS - phase UPGRADE 2955a2955 END - FAIL - phase UPGRADE Test Failed. *** End: Upgrade_10_1_10_2 jdk1.5.0_04 derbyall:upgrade 2006-08-15 18:02:14 ***
[jira] Commented: (DERBY-1693) Out of Memory Error with derby.language.logStatementText=true
[ http://issues.apache.org/jira/browse/DERBY-1693?page=comments#action_12428186 ] Manjula Kutty commented on DERBY-1693: -- My question is what should log statement text do. The easiest is just not print values for the blob/clob. Is that ok? I have more prefrence to not to print the values for the blob /clob. This will solve 2 problems: 1. The out of memory error 2. the derby.log will become more cleaner (without those binary values for the blob) 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.0.0 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 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
Re: [jira] Commented: (DERBY-1057) documentation to address Grant/Revoke (Derby-464)
Yes, I will update the topics based on the comments from Mamta after these patches have been committed. On 8/15/06, Jean T. Anderson [EMAIL PROTECTED] wrote: I'll go ahead and commit. It looks to me that there are some outstanding comments by Mamta that can be rolled into the next pass. -jean -- Laura Stewart
Re: Difficulty finding source + instructions (Was Re: How to commit documentation patches?)
On 8/15/06, Jean T. Anderson [EMAIL PROTECTED] wrote: Information about source is spread out -- code source on the downloads page, doc source on the documentation tab, web site source on the community tab We could really use one page on Derby Source with info (or pointers) to all three, especially since svn info and tips could be consolidated for all three. -jean *** (LS) I agree, it would be very useful to have the info/tips consolidated and then links to the various source pages. -- Laura Stewart
[jira] Commented: (DERBY-1057) documentation to address Grant/Revoke (Derby-464)
[ http://issues.apache.org/jira/browse/DERBY-1057?page=comments#action_12428187 ] Jean T. Anderson commented on DERBY-1057: - The doc build fails after applying derby1057_devguide4.ddiff . I downloaded the patch twice, also did a clean doc build before applying the patch a second time. The problem is with src/devguide/rdevcsecure131.dita : [xslt] Unknown file: Fatal Error! Premature end of file. [xslt] Failed to process /home/jta/DB-DERBY-SVN/derby/docs/trunk/temp/rdevcsecure131.dita It looks like the file got clobbered. After applying the patch it has a file size of 0: $ ls -l rdevcsecure131.dita -rw-rw-r-- 1 jta jta 0 Aug 15 10:56 rdevcsecure131.dita After reverting the change, file size is now 0: [EMAIL PROTECTED] devguide]$ svn revert rdevcsecure131.dita Reverted 'rdevcsecure131.dita' [EMAIL PROTECTED] devguide]$ ls -l rdevcsecure131.dita -rw-rw-r-- 1 jta jta 2298 Aug 15 11:06 rdevcsecure131.dita Laura, could you do a doc build on your machine, then create and upload a new patch? thanks! -jean documentation to address Grant/Revoke (Derby-464) - Key: DERBY-1057 URL: http://issues.apache.org/jira/browse/DERBY-1057 Project: Derby Issue Type: Sub-task Components: Documentation Affects Versions: 10.0.2.0 Reporter: Eric Radzinski Assigned To: Laura Stewart Fix For: 10.2.0.0 Attachments: derby1057_devguide.diff, derby1057_devguide3.diff, derby1057_devguide4.ddiff, derby1057_devguide_html.zip, derby1057_devguide_html3.zip, derby1057_devguide_html4.zip, derby1057_ref.diff, derby1057_ref3.diff, derby1057_ref4.diff, derby1057_ref_html.zip, derby1057_ref_html4.zip, derby1057_tuning3.diff, derby1057_tuning4.diff, derby1057_tuning_html.zip, derby1058_ref_html3.zip, devguide_html2.zip, ref_html2.zip, rtunpropersqlauth.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: [jira] Commented: (DERBY-1057) documentation to address Grant/Revoke (Derby-464)
On 8/15/06, Jean T. Anderson (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-1057?page=comments#action_12428187 ] The doc build fails after applying derby1057_devguide4.ddiff . I downloaded the patch twice, also did a clean doc build before applying the patch a second time. The problem is with src/devguide/rdevcsecure131.dita : ... Laura, could you do a doc build on your machine, then create and upload a new patch? Sure, will do that now. -- Laura Stewart
[jira] Commented: (DERBY-415) sysinfo with -cp client option should not print error saying DB2 jar file and driver class are missing
[ http://issues.apache.org/jira/browse/DERBY-415?page=comments#action_12428188 ] Andrew McIntyre commented on DERBY-415: --- This patch looks good to me, clean and simple. +1 to commit. sysinfo with -cp client option should not print error saying DB2 jar file and driver class are missing -- Key: DERBY-415 URL: http://issues.apache.org/jira/browse/DERBY-415 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.1.1.0 Reporter: David Van Couvering Assigned To: Bryan Pendleton Priority: Minor Attachments: derby-415-cp-db2driver.diff, derby-415.diff If you run java org.apache.derby.tools.sysinfo -cp client SimpleApp.class you get FOUND IN CLASS PATH: Derby Client libraries (derbyclient.jar) user-specified class (SimpleApp) NOT FOUND IN CLASS PATH: Derby Client libraries (db2jcc.jar) (com.ibm.db2.jcc.DB2Driver not found.) The NOT FOUND IN CLASSPATH output is confusing and invalid because we're testing the network client, not the DB2 JCC client. -- 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-1057) documentation to address Grant/Revoke (Derby-464)
On 8/15/06, Laura Stewart [EMAIL PROTECTED] wrote: On 8/15/06, Jean T. Anderson (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-1057?page=comments#action_12428187 ] The doc build fails after applying derby1057_devguide4.ddiff . I downloaded the patch twice, also did a clean doc build before applying the patch a second time. The problem is with src/devguide/rdevcsecure131.dita : ... Laura, could you do a doc build on your machine, then create and upload a new patch? Sure, will do that now. ***(LS) Actually that file should be deleted. As part of the documentation updates for grant/revoke, I had to do some rearrangement of information. The examples that were in that file were moved into another file. The files that were deleted are: rdevcsecure131 rdevcsecure935 -- Laura Stewart
Re: [jira] Commented: (DERBY-1057) documentation to address Grant/Revoke (Derby-464)
Laura Stewart wrote: On 8/15/06, Laura Stewart [EMAIL PROTECTED] wrote: On 8/15/06, Jean T. Anderson (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-1057?page=comments#action_12428187 ] The doc build fails after applying derby1057_devguide4.ddiff . I downloaded the patch twice, also did a clean doc build before applying the patch a second time. The problem is with src/devguide/rdevcsecure131.dita : ... Laura, could you do a doc build on your machine, then create and upload a new patch? Sure, will do that now. ***(LS) Actually that file should be deleted. As part of the documentation updates for grant/revoke, I had to do some rearrangement of information. The examples that were in that file were moved into another file. The files that were deleted are: rdevcsecure131 rdevcsecure935 ok, thanks, I'll delete them on my end -- no need to create/upload new patch. -jean
[jira] Commented: (DERBY-1057) documentation to address Grant/Revoke (Derby-464)
[ http://issues.apache.org/jira/browse/DERBY-1057?page=comments#action_12428190 ] Laura Stewart commented on DERBY-1057: -- ***(LS) Actually that file should be deleted. As part of the documentation updates for grant/revoke, I had to do some rearrangement of information. The examples that were in that file were moved into another file. The files that were deleted are: rdevcsecure131 rdevcsecure935 documentation to address Grant/Revoke (Derby-464) - Key: DERBY-1057 URL: http://issues.apache.org/jira/browse/DERBY-1057 Project: Derby Issue Type: Sub-task Components: Documentation Affects Versions: 10.0.2.0 Reporter: Eric Radzinski Assigned To: Laura Stewart Fix For: 10.2.0.0 Attachments: derby1057_devguide.diff, derby1057_devguide3.diff, derby1057_devguide4.ddiff, derby1057_devguide_html.zip, derby1057_devguide_html3.zip, derby1057_devguide_html4.zip, derby1057_ref.diff, derby1057_ref3.diff, derby1057_ref4.diff, derby1057_ref_html.zip, derby1057_ref_html4.zip, derby1057_tuning3.diff, derby1057_tuning4.diff, derby1057_tuning_html.zip, derby1058_ref_html3.zip, devguide_html2.zip, ref_html2.zip, rtunpropersqlauth.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
anyone available to review blocker 1633, I am willing to act as committer?
Is there anyone who has some time to review DERBY-1633, Regression: The fields of views are not being calculated properly since 10.1.2.4. This looks like a pretty serious problem, and the patch is available. I don't have much expertise in this area, but am happy to pick up the patch, look at it and run the tests. I would like someone else, does not need to be a committer, to review the changes.
[jira] Resolved: (DERBY-1691) jdbcapi/blobclob4BLOB.java fails under DerbyNet framework with JCC 2.6
[ http://issues.apache.org/jira/browse/DERBY-1691?page=all ] David Van Couvering resolved DERBY-1691. Resolution: Fixed Assignee: David Van Couvering I've committed revision 431663, hopefully this should make the diff go away. jdbcapi/blobclob4BLOB.java fails under DerbyNet framework with JCC 2.6 -- Key: DERBY-1691 URL: http://issues.apache.org/jira/browse/DERBY-1691 Project: Derby Issue Type: Bug Components: Test, Regression Test Failure Affects Versions: 10.2.0.0 Environment: Linux 2.6.9-5.ELsmp Sun jdk 1.5.0_07-b03 Reporter: Rajesh Kartha Assigned To: David Van Couvering Fix For: 10.2.0.0 With JCC 2.6, the jdbcapi/blobclob4BLOB.java fails. The diff did not show anything alarming, so I am guessing it may be a master update. The test passed fine with DerbyClient *** Start: blobclob4BLOB jdk1.5.0_06 DerbyNet derbynetmats:jdbcapi 2006-08-11 23:29:48 *** 466a467,474 EXPECTED SQLSTATE(22018): Invalid character string format for type INTEGER. end clobTest54 START: clobTest6 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 FAIL -- unexpected exception:java.lang.StringIndexOutOfBoundsException: String index out of range: -1 468,475d475 EXPECTED SQLSTATE(22018): Invalid character string format for type INTEGER. end clobTest54 START: clobTest6 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 FAIL -- unexpected exception:java.lang.StringIndexOutOfBoundsException: String index out of range: -1 775a776,782 blobTest54 finished START: blobTest6 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 FAIL -- unexpected exception:java.lang.NegativeArraySizeException 777,783d783 blobTest54 finished START: blobTest6 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 FAIL -- unexpected exception:java.lang.NegativeArraySizeException 789 del com.ibm.db2.jcc.c.SqlException: Operation 'CREATE TRIGGER' cannot be performed on object 'TESTBLOB' because there is an open ResultSet dependent on that object. 789a789 com.ibm.db2.jcc.a.SqlException: Operation 'CREATE TRIGGER' cannot be performed on object 'TESTBLOB' because there is an open ResultSet dependent on that object. Test Failed. *** End: blobclob4BLOB jdk1.5.0_06 DerbyNet derbynetmats:jdbcapi 2006-08-11 23:30:46 *** -- 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-1057) documentation to address Grant/Revoke (Derby-464)
[ http://issues.apache.org/jira/browse/DERBY-1057?page=comments#action_12428192 ] Andrew McIntyre commented on DERBY-1057: I applied the devguide4 diff and even though the contents of rdevsecure131 and rdevsecure935 were removed, references to these files remained in the devguide.ditamap. I think this is why Jean was seeing a problem with the build originally. Some of these files contain a comment line that includes Arbortext, Inc. Can these be removed? documentation to address Grant/Revoke (Derby-464) - Key: DERBY-1057 URL: http://issues.apache.org/jira/browse/DERBY-1057 Project: Derby Issue Type: Sub-task Components: Documentation Affects Versions: 10.0.2.0 Reporter: Eric Radzinski Assigned To: Laura Stewart Fix For: 10.2.0.0 Attachments: derby1057_devguide.diff, derby1057_devguide3.diff, derby1057_devguide4.ddiff, derby1057_devguide_html.zip, derby1057_devguide_html3.zip, derby1057_devguide_html4.zip, derby1057_ref.diff, derby1057_ref3.diff, derby1057_ref4.diff, derby1057_ref_html.zip, derby1057_ref_html4.zip, derby1057_tuning3.diff, derby1057_tuning4.diff, derby1057_tuning_html.zip, derby1058_ref_html3.zip, devguide_html2.zip, ref_html2.zip, rtunpropersqlauth.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: [jira] Commented: (DERBY-1057) documentation to address Grant/Revoke (Derby-464)
Andrew McIntyre (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1057?page=comments#action_12428192 ] Andrew McIntyre commented on DERBY-1057: I applied the devguide4 diff and even though the contents of rdevsecure131 and rdevsecure935 were removed, references to these files remained in the devguide.ditamap. I think this is why Jean was seeing a problem with the build originally. I'll update the ditamap -- thanks for the catch. Some of these files contain a comment line that includes Arbortext, Inc. Can these be removed? these should be removed -- I'm pretty sure these are just side effects of the editor Laura is using, right Laura? At any rate, let's do a separate sweep through all books for this one, ok? -jean
Re: [jira] Commented: (DERBY-1057) documentation to address Grant/Revoke (Derby-464)
Jean T. Anderson wrote: Andrew McIntyre (JIRA) wrote: ... Some of these files contain a comment line that includes Arbortext, Inc. Can these be removed? these should be removed -- I'm pretty sure these are just side effects of the editor Laura is using, right Laura? At any rate, let's do a separate sweep through all books for this one, ok? actually I see that these are in the current patch, so I'll go ahead and remove them. Just a few made it into other books as well. -jean
Re: some minor doc warnings on the truk...
Suresh Thalamati wrote:
[javadoc]
C:\nightlies\main\src\opensource\java\engine\org\apache\derby\iapi\types\XML.java:262:
warning - Tag @see: can't find setFrom
org.apache.derby.iapi.types.DataValueDescriptor
[javadoc]
C:\nightlies\main\src\opensource\java\engine\org\apache\derby\iapi\types\XML.java:163:
warning - @param argument qualXType is not a parameter name.
Attached patch should fix these two javadoc errors in XML.java. Thanks for
catching these, Suresh.
Army
Index: java/engine/org/apache/derby/iapi/types/XML.java
===
--- java/engine/org/apache/derby/iapi/types/XML.java(revision 431636)
+++ java/engine/org/apache/derby/iapi/types/XML.java(working copy)
@@ -158,7 +158,6 @@
* object's qualified type.
* @param val A SQLChar instance to clone and use for
* this XML value.
- * @param qualXType Qualified XML type.
*/
private XML(SQLChar val, int xmlType)
{
@@ -255,9 +254,7 @@
}
/**
- * @see DataValueDescriptor#setFrom
- *
- * Note:
+ * @see DataType#setFrom
*/
protected void setFrom(DataValueDescriptor theValue)
throws StandardException
Index: java/engine/org/apache/derby/iapi/types/DataType.java
===
--- java/engine/org/apache/derby/iapi/types/DataType.java (revision
431636)
+++ java/engine/org/apache/derby/iapi/types/DataType.java (working copy)
@@ -478,6 +478,14 @@
}
}
+ /**
+* Set the value of this DataValueDescriptor based on the value
+* of the specified DataValueDescriptor.
+*
+* @param dvd The DataValueDescriptor that holds the value to
+* which we want to set this DataValueDescriptor's value.
+*
+*/
protected void setFrom(DataValueDescriptor dvd) throws StandardException
{
throw StandardException.newException(SQLState.NOT_IMPLEMENTED);
[junit] Move JUnit base/utility classes???
Currently the JUnit base and utility classes are in this package: org.apache.derbyTesting.functionTests.util (See http://wiki.apache.org/db-derby/DerbyJUnitTesting) I was wondering if they should be moved, for two reasons: 1) That package is cluttered up with other stuff, it's more or less a dumping ground. Utilites, JUnit base classes, user level classes for procedures and vtis, etc. 2) JUnit tests can be much more than funcional tests, e.g. having system tests as JUnit tests would make them easy for everyone to run. I was thinking of the following package: org.apache.derbyTesting.junit The package would be limited to base classes for JUnit tests and JUnit related utilities such as the JDBC class. Classes for specific tests, or those that implement Java procedures for tests etc. would not be allowed. The functional tests would continue to live in their current location, just that the super-class BaseJDBCTestCase would be in the new package. Thoughts? Dan.
[jira] Created: (DERBY-1698) Add more tests for Statement.setQueryTimeout method
Add more tests for Statement.setQueryTimeout method --- Key: DERBY-1698 URL: http://issues.apache.org/jira/browse/DERBY-1698 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.2.0.0, 10.3.0.0 Reporter: Deepa Remesh Priority: Minor Currently, the following checks work as expected but it would be good to add them to regression tests: * Add tests to check query timeout value is used by executeUpdate method. Existing test tests calls to execute and executeQuery. The following mail mentions query timeout limit should be applied for all executeXXX methods. http://www.nabble.com/Statement.setQueryTimeout-tf94429.html#a258410 * Add tests for Statement and CallableStatement class. Existing test tests this method with PreparedStatement only. I found a difference in behaviour with client driver when using Statement class (DERBY-1692). So it may be good to add some tests for each statement class. -- 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-1698) Add more tests for Statement.setQueryTimeout method
[ http://issues.apache.org/jira/browse/DERBY-1698?page=all ] Deepa Remesh reassigned DERBY-1698: --- Assignee: Deepa Remesh Add more tests for Statement.setQueryTimeout method --- Key: DERBY-1698 URL: http://issues.apache.org/jira/browse/DERBY-1698 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.2.0.0, 10.3.0.0 Reporter: Deepa Remesh Assigned To: Deepa Remesh Priority: Minor Currently, the following checks work as expected but it would be good to add them to regression tests: * Add tests to check query timeout value is used by executeUpdate method. Existing test tests calls to execute and executeQuery. The following mail mentions query timeout limit should be applied for all executeXXX methods. http://www.nabble.com/Statement.setQueryTimeout-tf94429.html#a258410 * Add tests for Statement and CallableStatement class. Existing test tests this method with PreparedStatement only. I found a difference in behaviour with client driver when using Statement class (DERBY-1692). So it may be good to add some tests for each statement class. -- 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-1057) documentation to address Grant/Revoke (Derby-464)
[ http://issues.apache.org/jira/browse/DERBY-1057?page=comments#action_12428196 ] Jean T. Anderson commented on DERBY-1057: - Committed revision 431680 patch derby1057_devguide4.ddiff , plus these additional modifications: - 'svn del' on the rdevcsecure131.dita and rdevcsecure935.dita files. - Removed entries for the deleted files from derbydev.ditamap. - Removed Arbortext comments. The Subversion Commits tab should reflect the files added, deleted, and modified, but since this patch needed some additional changes, here's what it looked like in my working copy: $ svn status M src/devguide/cdevcsecure42374.dita M src/devguide/cdevcsecure866060.dita M src/devguide/derbydev.ditamap A src/devguide/cdevcsecuregrantrevokeaccess.dita M src/devguide/cdevcsecure36595.dita D src/devguide/rdevcsecure935.dita M src/devguide/rdevcsecure379.dita M src/devguide/rdevcsecure190.dita D src/devguide/rdevcsecure131.dita M src/devguide/cdevcsecure865818.dita M src/devguide/cdevcsecure865880.dita documentation to address Grant/Revoke (Derby-464) - Key: DERBY-1057 URL: http://issues.apache.org/jira/browse/DERBY-1057 Project: Derby Issue Type: Sub-task Components: Documentation Affects Versions: 10.0.2.0 Reporter: Eric Radzinski Assigned To: Laura Stewart Fix For: 10.2.0.0 Attachments: derby1057_devguide.diff, derby1057_devguide3.diff, derby1057_devguide4.ddiff, derby1057_devguide_html.zip, derby1057_devguide_html3.zip, derby1057_devguide_html4.zip, derby1057_ref.diff, derby1057_ref3.diff, derby1057_ref4.diff, derby1057_ref_html.zip, derby1057_ref_html4.zip, derby1057_tuning3.diff, derby1057_tuning4.diff, derby1057_tuning_html.zip, derby1058_ref_html3.zip, devguide_html2.zip, ref_html2.zip, rtunpropersqlauth.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
Regression Test Failure! - TinderBox_Derby 431634 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 431634/2006-08-15 18:13:32 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 2677675 2 156.59% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-431634.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/431634.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/431634.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Commented: (DERBY-1652) Update trigger updating the same rows as the original update does not throw an exception ERROR 54038: Maximum depth of nested triggers was exceeded as it should
[ http://issues.apache.org/jira/browse/DERBY-1652?page=comments#action_12428199 ] Kathey Marsden commented on DERBY-1652: --- Yip said I thought they were negative tests with wrong results Thanks Yip, I think I got confused because of the comments: --after and the trigger name: tgood don't lend themselves to a negative test. If more work is done on the patch it might be good to change them for clarity moving forward. ij -- after create trigger tgood after insert on x for each statement mode db2sql insert into x values 666; 0 rows inserted/updated/deleted ij insert into x values 1; ERROR 54038: Maximum depth of nested triggers was exceeded. Update trigger updating the same rows as the original update does not throw an exception ERROR 54038: Maximum depth of nested triggers was exceeded as it should --- Key: DERBY-1652 URL: http://issues.apache.org/jira/browse/DERBY-1652 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.0.2.0, 10.2.0.0, 10.1.3.1 Reporter: Kathey Marsden Assigned To: Yip Ng Fix For: 10.2.0.0, 10.1.3.2 Attachments: derby1652-10.1.3-diff.txt, derby1652-10.1.3-stat.txt, derby1652-trunk-diff01.txt, derby1652-trunk-stat01.txt Execution of an update trigger that updates the same row as the original update will recurse forever and exceed the maximum nesting level of 16 so should throw the exception: ERROR 54038: Maximum depth of nested triggers was exceeded However, it does not always throw the exception. For example: CREATE TABLE TEST ( TESTID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1), INFO INTEGER NOT NULL, TIMESTAMP TIMESTAMP NOT NULL DEFAULT '1980-01-01-00.00.00.00' ); CREATE TRIGGER UPDATE_TEST AFTER UPDATE ON TEST REFERENCING OLD AS OLD FOR EACH ROW MODE DB2SQL UPDATE TEST SET TIMESTAMP = CURRENT_TIMESTAMP WHERE TESTID = OLD.TESTID; INSERT INTO TEST (INFO) VALUES (1), (2), (3); UPDATE TEST SET INFO = 1 WHERE TESTID = 2; Does not throw an exception: However, If the derby jars are updated to a new version, the correct exception is thrown. Replace derby jars with new version Execute the following in ij: UPDATE TEST SET INFO = 1 WHERE TESTID = 2; ERROR 54038: Maximum depth of nested triggers was exceeded. Note: This issue stemmed from the Invalid issue, DERBY-1603, because a user hit the exception after upgrade and thought the exception after upgrade, not the lack of exception before upgrade was the problem. This may be a common user error, so we need a release note to help mitigate the issue.I will add one shortly after confirming the correct trigger syntax. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Db-derby Wiki] Update of TenTwoBuddyTesting by DeepaRemesh
Deepa, if a doc update is required, can you please open an issue for this? On 8/15/06, Apache Wiki [EMAIL PROTECTED] wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Db-derby Wiki for change notification. The following page has been changed by DeepaRemesh: http://wiki.apache.org/db-derby/TenTwoBuddyTesting -- || * New metadata API ||[http://issues.apache.org/jira/browse/DERBY-924 DERBY-924],[http://issues.apache.org/jira/browse/DERBY-925 DERBY-925] || || || || || '''Unary plus/minus for parameters''' || [http://issues.apache.org/jira/browse/DERBY-582 DERBY-582] || || || || || '''FOR UPDATE clause''' || [http://issues.apache.org/jira/browse/DERBY-231 DERBY-231] || || || || - || '''Client timeout mechanism''' || [http://issues.apache.org/jira/browse/DERBY-506 DERBY-506] || Deepa || || || + || '''Client timeout mechanism''' || [http://issues.apache.org/jira/browse/DERBY-506 DERBY-506] || Deepa || This method was listed as not implemented in 10.1 reference manual. Verified that 10.2 documents do not mention this method as not implemented. No other documentation for this feature other than javadoc. || Found 1 issue - [http://issues.apache.org/jira/browse/DERBY-1692 DERBY-1692]. Opened [http://issues.apache.org/jira/browse/DERBY-1698 DERBY-1698] to contribute the tests I have written for this. || || '''Optimizer directives''' || [http://issues.apache.org/jira/browse/DERBY-573 DERBY-573] || Deepa || || || || '''XML support for XPath and JDBC''' || [http://issues.apache.org/jira/browse/DERBY-688 DERBY-688] ||Suresh|| 1 Patch waiting review another patch needs to be drafted || || || '''Grant Revoke''' || [http://issues.apache.org/jira/browse/DERBY-464 DERBY-464] ||Yip || Updates to the Tuning Guide committed. Patches for the Dev Guide and Ref Manual waiting review || || -- Laura Stewart
[jira] Commented: (DERBY-1692) Client driver does not use the query timeout value set using Statement.setQueryTimeout() for subsequent executions using the same statement object
[ http://issues.apache.org/jira/browse/DERBY-1692?page=comments#action_12428205 ] Knut Anders Hatlen commented on DERBY-1692: --- I think this happens because the client only sends the timeout value when it has changed. For PreparedStatement and CallableStatement this is OK since there is a one-to-one correspondence between these kinds of statements on the client and on the server. For a Statement object on the client, a new PreparedStatement is created on the server each time one of the execute methods is called. Therefore, the timeout value should be sent each time a Statement is executed. Client driver does not use the query timeout value set using Statement.setQueryTimeout() for subsequent executions using the same statement object -- Key: DERBY-1692 URL: http://issues.apache.org/jira/browse/DERBY-1692 Project: Derby Issue Type: Bug Components: Network Client, Network Server Affects Versions: 10.2.0.0, 10.3.0.0 Reporter: Deepa Remesh Attachments: TestQueryTimeout.java I will attach a repro with more details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1691) jdbcapi/blobclob4BLOB.java fails under DerbyNet framework with JCC 2.6
[ http://issues.apache.org/jira/browse/DERBY-1691?page=comments#action_12428209 ] Craig Russell commented on DERBY-1691: -- There is a tiny difference in the message text for: com.ibm.db2.jcc.c.SqlException com.ibm.db2.jcc.a.SqlException Is the difference something needs to be explained? Craig jdbcapi/blobclob4BLOB.java fails under DerbyNet framework with JCC 2.6 -- Key: DERBY-1691 URL: http://issues.apache.org/jira/browse/DERBY-1691 Project: Derby Issue Type: Bug Components: Test, Regression Test Failure Affects Versions: 10.2.0.0 Environment: Linux 2.6.9-5.ELsmp Sun jdk 1.5.0_07-b03 Reporter: Rajesh Kartha Assigned To: David Van Couvering Fix For: 10.2.0.0 With JCC 2.6, the jdbcapi/blobclob4BLOB.java fails. The diff did not show anything alarming, so I am guessing it may be a master update. The test passed fine with DerbyClient *** Start: blobclob4BLOB jdk1.5.0_06 DerbyNet derbynetmats:jdbcapi 2006-08-11 23:29:48 *** 466a467,474 EXPECTED SQLSTATE(22018): Invalid character string format for type INTEGER. end clobTest54 START: clobTest6 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 FAIL -- unexpected exception:java.lang.StringIndexOutOfBoundsException: String index out of range: -1 468,475d475 EXPECTED SQLSTATE(22018): Invalid character string format for type INTEGER. end clobTest54 START: clobTest6 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 FAIL -- unexpected exception:java.lang.StringIndexOutOfBoundsException: String index out of range: -1 775a776,782 blobTest54 finished START: blobTest6 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 FAIL -- unexpected exception:java.lang.NegativeArraySizeException 777,783d783 blobTest54 finished START: blobTest6 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 FAIL -- unexpected exception:java.lang.NegativeArraySizeException 789 del com.ibm.db2.jcc.c.SqlException: Operation 'CREATE TRIGGER' cannot be performed on object 'TESTBLOB' because there is an open ResultSet dependent on that object. 789a789 com.ibm.db2.jcc.a.SqlException: Operation 'CREATE TRIGGER' cannot be performed on object 'TESTBLOB' because there is an open ResultSet dependent on that object. Test Failed. *** End: blobclob4BLOB jdk1.5.0_06 DerbyNet derbynetmats:jdbcapi 2006-08-11 23:30:46 *** -- 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: test failures caused by firewall software? (was Re: Regression Test Failure! - Derby 430109 - Sun DBTG)
Kathey Marsden wrote: Just FYI, I think there is something not quite right with network server's interaction with firewall software or maybe , where one can get a hang even though the software is set to allow connections. FYI - I'm seeing hangs in some of the tests when a wait for the server to be booted by pinging it fails. The test then hangs in trying to cleanup, rather than any hang in the network server. I see this with testSecMec and testProperties. I can get these tests to pass by bumping the wait time. Of course it's interesting that each test seems to have its own method to perform the wait and its own time to wait. I'm not sure I should be bumping the time for these tests, but I will commit the clean up for the tests. Maybe the increase in time i just due ot my machine or it points to a real problem with the server. Dan.
[jira] Commented: (DERBY-495) COALESCE
[ http://issues.apache.org/jira/browse/DERBY-495?page=comments#action_12428210 ] Matt Frantz commented on DERBY-495: --- The proposed documentation does not allow for the possibility of invoking COALESCE with a single argument. Should it read as follows? COALESCE (expression[,expression]...) If the single-argument case is not supported, then maybe it should be. (This case is nice for SQL-generator applications.) COALESCE Key: DERBY-495 URL: http://issues.apache.org/jira/browse/DERBY-495 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.0.2.0 Environment: n/a Reporter: Paul Jenkins Priority: Minor The COALESCE function has been implemeted since 10.0.2.0 (at least) but isn't documented. -- 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-1692) Client driver does not use the query timeout value set using Statement.setQueryTimeout() for subsequent executions using the same statement object
[ http://issues.apache.org/jira/browse/DERBY-1692?page=all ] Knut Anders Hatlen updated DERBY-1692: -- Attachment: derby-1692.diff The attached patch seems to fix the bug. I have not run (or written) any tests. Client driver does not use the query timeout value set using Statement.setQueryTimeout() for subsequent executions using the same statement object -- Key: DERBY-1692 URL: http://issues.apache.org/jira/browse/DERBY-1692 Project: Derby Issue Type: Bug Components: Network Client, Network Server Affects Versions: 10.2.0.0, 10.3.0.0 Reporter: Deepa Remesh Attachments: derby-1692.diff, TestQueryTimeout.java I will attach a repro with more details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1699) Save optimizer costs in saved obejcts rather than as compiled byte code, reduces memory usage and generated class size.
Save optimizer costs in saved obejcts rather than as compiled byte code, reduces memory usage and generated class size. --- Key: DERBY-1699 URL: http://issues.apache.org/jira/browse/DERBY-1699 Project: Derby Issue Type: Improvement Components: SQL Reporter: Daniel John Debrunner A UNION node will generate byte code to call this method: NoPutResultSet getUnionResultSet(NoPutResultSet source1, NoPutResultSet source2, Activation activation, int resultSetNumber, double optimizerEstimatedRowCount, double optimizerEstimatedCost, GeneratedMethod closeCleanup) The optimizer costs being passed in are rarely used, in some cases they are used as estimates for sizing items. They are also used if the plan is displayed, to show the costs. It's possible that the cost estimates could be saved in the saved objects structure of the plan and be available by result set number. E.g. .store a Hashtable in the saved objects with a key of costEstimates, the hashtable would have a key of resultSetNumber and value of a StoreCostResult. This would also be a one time storage at compile time, rather than the current code which incurs a both a cpu and memory cost at runtime for each ResultSet and hence each active query. This would apply to any node that takes an optimizer cost. This has been split out from DERBY-766 -- 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-1700) Remove passing of closeCleanup method to every ResultSet type since only the top ResultSet requires it.
Remove passing of closeCleanup method to every ResultSet type since only the top ResultSet requires it. --- Key: DERBY-1700 URL: http://issues.apache.org/jira/browse/DERBY-1700 Project: Derby Issue Type: Improvement Components: SQL Reporter: Daniel John Debrunner Assigned To: Daniel John Debrunner Priority: Minor A UNION node will generate byte code to call this method: NoPutResultSet getUnionResultSet(NoPutResultSet source1, NoPutResultSet source2, Activation activation, int resultSetNumber, double optimizerEstimatedRowCount, double optimizerEstimatedCost, GeneratedMethod closeCleanup) The closeCleanup method is passed in as null for all result sets in a tree except the top one. Instead of passing it on each new result set, it would be much more efficient to have a setCloseMethod() that is only called once for the top result set. Could also look at having an closeCleanup method in the interface and call it directly, rather than through reflection. This applies to any node that takes a closeCleanup method. Split out from DERBY-766 -- 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: [Db-derby Wiki] Update of TenTwoBuddyTesting by DeepaRemesh
On 8/15/06, Laura Stewart [EMAIL PROTECTED] wrote: Deepa, if a doc update is required, can you please open an issue for this? No further doc update is required for this. The information about this method is in the javadocs. The only doc change that was required was to update the reference manual to remove this method from not implemented list. I verified this is already done and noted this fact in Documentation Available column. Maybe, this is not the intent of this column. Looks like it is used to indicate the state of doc patches. I'll remove my comment from there. Thanks, Deepa
[jira] Commented: (DERBY-766) Improve code generation to handle 5000 unions in a select the union test in largeCodeGen
[ http://issues.apache.org/jira/browse/DERBY-766?page=comments#action_12428218 ] Daniel John Debrunner commented on DERBY-766: - Update: Change 1), don't pass in Activation when it can be obtained from another ResultSet Completed under this issue number. Change 2) The optimizer costs being passed in are rarely used. DERBY-1699 improvement entered to address it Change 3) The closeCleanup method is passed in as null for all result sets in a tree except the top one. DERBY-1700 improvement entered to address it Recent work under this issue has been to add generic code to CodeChunk and BCMethod that splits out expressions in the generated code into sub-methods if the generated code is bigger than the 64k limit imposed by the VM. Testing has shown that this increases the number of unions supported in the largeCodeGen test from ~800 to over 5,200. More testing is needed, basically running the split code at a low threshold with derbyall to ensure that the split works in all situations, e.g. split methods when they are overk 2k in size, instead of 64k. Improve code generation to handle 5000 unions in a select the union test in largeCodeGen -- Key: DERBY-766 URL: http://issues.apache.org/jira/browse/DERBY-766 Project: Derby Issue Type: Sub-task Components: Services Affects Versions: 10.2.0.0 Reporter: Kathey Marsden Assigned To: Daniel John Debrunner Fix For: 10.2.0.0 A good incremental improvement for code generation for 10.2 would be to handle 5000 unions in the largeCodeGen test. eg. largeUnionSelect(con, viewName, 5000); should pass. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1114) derbynet/testSecMec.java fails intermittently and test exits mysteriously when server is shutdown as part of the testrun.
[ http://issues.apache.org/jira/browse/DERBY-1114?page=comments#action_12428221 ] Kathey Marsden commented on DERBY-1114: --- Thanks Dan. Upping the time did the trick for me as well. derbynet/testSecMec.java fails intermittently and test exits mysteriously when server is shutdown as part of the testrun. - Key: DERBY-1114 URL: http://issues.apache.org/jira/browse/DERBY-1114 Project: Derby Issue Type: Bug Components: Network Server, Test Affects Versions: 10.2.0.0 Environment: Java Version:1.4.2_06 Java Vendor: Sun Microsystems Inc. Java home: /usr/local/lib/j2sdk1.4.2_06/jre OS name: Linux OS architecture: i386 OS version: 2.4.21-27.0.2.ELsmp Reporter: Sunitha Kambhampati Assigned To: Bryan Pendleton Priority: Minor Attachments: Derby1114.diff.txt, Stdout.java, testSecMec_test_output.zip The test derbynet/testSecMec.java fails intermittently in a strange way that the test actually exits before finishing the full test. This issue was noticed by Bryan when he ran derbyall with the derby-1080 fix. Some discussion and analysis that has been done is in Derby-1080. Please read comments in DERBY-1080. Some main links in http://issues.apache.org/jira/browse/DERBY-1080#action_12370260 http://issues.apache.org/jira/browse/DERBY-1080#action_12370374 In short: the test does some switching of System.out and System.err streams before calling networkserver.shutdown. This code was added to this test as part of fix for derby-273. for some reason, the networkserver.shutdown call makes the test to exit. One theory is that the network server.shutdown is causing the standard out streams to close and thus the test exits. -- Need to investigate what is the cause for this intermittent failure and how/why networkserver.shutdown is closing the stream or making the test to exit prematurely. -- 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-1701) out of memory failures with the jdbcapi junit suite when run under derbynetclientsmats suite
out of memory failures with the jdbcapi junit suite when run under derbynetclientsmats suite Key: DERBY-1701 URL: http://issues.apache.org/jira/browse/DERBY-1701 Project: Derby Issue Type: Bug Components: Regression Test Failure Reporter: Mike Matrigali It looks like the jdbcapi junit suite has been failing on some platforms ever since change: r431195 | djd | 2006-08-13 19:08:04 +0200 (Sun, 13 Aug 2006) | 5 lines Have the test harness jdbcapi run a single JUnit suite jdbcapi._Suite that includes most of the JUnit tests that were run individually. Tests in this suite that were excluded in derby net or had _app.properties file now self-exclude themselves based upon the JUnit utility methods indicating which JDBC client they are running. Remaining JUnit tests should be included in jdbcapi._Suite, think they were added after I has started the _Suite work. Here is an example of the diff from the public regression tests: http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/testlog/CYGWIN_NT-5.1_i686-unknown/431200-derbyall_diff.txt *** Start: _Suite jdk1.4.2_10 DerbyNetClient derbynetmats:jdbcapi 2006-08-14 05:58:32 *** 0 add ..E There was 1 error: 1) testNextOnLastRowScrollable(org.apache.derbyTesting.functionTests.tests.jdbcapi.ScrollResultSetTest)java.lang.OutOfMemoryError FAILURES!!! Tests run: 817, Failures: 0, Errors: 1 Test Failed. *** End: _Suite jdk1.4.2_10 DerbyNetClient derbynetmats:jdbcapi 2006-08-14 06:01:05 *** Here are links to some of the failures that have been recorded: 1.4.2 failed on windows nt, and linux: http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/testlog/CYGWIN_NT-5.1_i686-unknown/431200-derbyall_diff.txt http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/testlog/Linux-2.6.9-34.ELsmp_x86_64-x86_64/431200-derbyall_diff.txt http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/testlog/CYGWIN_NT-5.1_i686-unknown/431386-derbyall_diff.txt http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/testlog/Linux-2.6.14-1.1644_FC4_i686-i686/431386-derbyall_diff.txt http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/testlog/Linux-2.6.9-34.ELsmp_x86_64-x86_64/431386-derbyall_diff.txt failed on jdk1.5: http://www.multinet.no/~solberg/public/Apache/Derby/testlog/CYGWIN_NT-5.1_i686-unknown/431386-derbyall_diff.txt That is just some of the places I saw it failed. It failed in my personal test runs on windows XP, run from sane classes, on single processor laptop. Failed consistently when run from the derbynetclientsmats suite on 2 trys, and once on a full nightly run. -- 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: [Db-derby Wiki] Update of TenTwoBuddyTesting by DeepaRemesh
On 8/15/06, Deepa Remesh [EMAIL PROTECTED] wrote: On 8/15/06, Laura Stewart [EMAIL PROTECTED] wrote: Deepa, if a doc update is required, can you please open an issue for this? No further doc update is required for this. The information about this method is in the javadocs. The only doc change that was required was to update the reference manual to remove this method from not implemented list. I verified this is already done and noted this fact in Documentation Available column. Maybe, this is not the intent of this column. Looks like it is used to indicate the state of doc patches. I'll remove my comment from there. Thanks, Deepa Actually Deepa, I think that it is appropriate to inidate that the updates to the documentation were verfied/validated in that column. I just wanted to be sure that, in addition to the javadoc, that no other updates are required. -- Laura Stewart
DERBY-1057 : patch Derby1057_ref4.diff and a G svn status
Applying derby1057_ref4.diff gets Reversed (or previously applied) patch detected! Assume -R? so I did this trick: svn up -r 431389 patch -p0 -i derby1057_ref4.diff svn up 'svn status' shows everything looks good except for the ditamap file: G src/ref/refderby.ditamap I'm looking for info about that G status and am not finding it at http://svnbook.red-bean.com/en/1.0/re26.html , but I vaguely recall from other ASF projects that it means something about local modifications colliding with what is checked into the server. The doc build succeeds. Is it safe to just go ahead and commit this? thanks, -jean
[jira] Commented: (DERBY-1636) document encryption of an un-encrypted database and re-encryption with new password/key.
[ http://issues.apache.org/jira/browse/DERBY-1636?page=comments#action_12428222 ] Laura Stewart commented on DERBY-1636: -- The spec indicates that the newEncryptionKey attribute should be used with the encryptionKey attribute. I don't see the encryptionKey attribute documented in the Derby docs... anywhere. Can you please check on this? document encryption of an un-encrypted database and re-encryption with new password/key. -- Key: DERBY-1636 URL: http://issues.apache.org/jira/browse/DERBY-1636 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.2.0.0 Reporter: Suresh Thalamati Assigned To: Laura Stewart Fix For: 10.2.0.0 Attachments: reencrypt_devgudechanges.txt, reencryptspec_1.html document encryption of an un-encrypted database and re-encryption with new password/key. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: anyone available to review blocker 1633, I am willing to act as committer?
Hi Mike, I will take a look at this patch. Regards, -Rick Mike Matrigali wrote: Is there anyone who has some time to review DERBY-1633, Regression: The fields of views are not being calculated properly since 10.1.2.4. This looks like a pretty serious problem, and the patch is available. I don't have much expertise in this area, but am happy to pick up the patch, look at it and run the tests. I would like someone else, does not need to be a committer, to review the changes.
Re: DERBY-1057 : patch Derby1057_ref4.diff and a G svn status
Actually, it must have been the second 'svn up' that reported the G because an 'svn status' now shows M. Since the doc build succeeds, I'll commit this. sorry for the noisy confusion, -jean Jean T. Anderson wrote: Applying derby1057_ref4.diff gets Reversed (or previously applied) patch detected! Assume -R? so I did this trick: svn up -r 431389 patch -p0 -i derby1057_ref4.diff svn up 'svn status' shows everything looks good except for the ditamap file: G src/ref/refderby.ditamap I'm looking for info about that G status and am not finding it at http://svnbook.red-bean.com/en/1.0/re26.html , but I vaguely recall from other ASF projects that it means something about local modifications colliding with what is checked into the server. The doc build succeeds. Is it safe to just go ahead and commit this? thanks, -jean
[jira] Updated: (DERBY-1652) Update trigger updating the same rows as the original update does not throw an exception ERROR 54038: Maximum depth of nested triggers was exceeded as it should
[ http://issues.apache.org/jira/browse/DERBY-1652?page=all ] Mike Matrigali updated DERBY-1652: -- I reproduced the out of memory on my machine in a clean codeline so do not believe it is caused by this patch. I also have reported DERBY-1701 for those out of memory errors which have been showing up in the public regression test runs on a number of platforms. I committed this patch as is, feeling the comments above were not worth holding up the patch. They seem like good things to do, but not necessary to hold up the fix. m1_142:97svn commit Sending java\engine\org\apache\derby\impl\sql\execute\CreateTriggerConstantAction.java Sending java\engine\org\apache\derby\impl\store\raw\data\OverflowInputStream.java Sending java\testing\org\apache\derbyTesting\functionTests\master\triggerGeneral.out Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\triggerGeneral.sql Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\updatableResultSet.java Transmitting file data . Committed revision 431698. Update trigger updating the same rows as the original update does not throw an exception ERROR 54038: Maximum depth of nested triggers was exceeded as it should --- Key: DERBY-1652 URL: http://issues.apache.org/jira/browse/DERBY-1652 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.0.2.0, 10.2.0.0, 10.1.3.1 Reporter: Kathey Marsden Assigned To: Yip Ng Fix For: 10.2.0.0, 10.1.3.2 Attachments: derby1652-10.1.3-diff.txt, derby1652-10.1.3-stat.txt, derby1652-trunk-diff01.txt, derby1652-trunk-stat01.txt Execution of an update trigger that updates the same row as the original update will recurse forever and exceed the maximum nesting level of 16 so should throw the exception: ERROR 54038: Maximum depth of nested triggers was exceeded However, it does not always throw the exception. For example: CREATE TABLE TEST ( TESTID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1), INFO INTEGER NOT NULL, TIMESTAMP TIMESTAMP NOT NULL DEFAULT '1980-01-01-00.00.00.00' ); CREATE TRIGGER UPDATE_TEST AFTER UPDATE ON TEST REFERENCING OLD AS OLD FOR EACH ROW MODE DB2SQL UPDATE TEST SET TIMESTAMP = CURRENT_TIMESTAMP WHERE TESTID = OLD.TESTID; INSERT INTO TEST (INFO) VALUES (1), (2), (3); UPDATE TEST SET INFO = 1 WHERE TESTID = 2; Does not throw an exception: However, If the derby jars are updated to a new version, the correct exception is thrown. Replace derby jars with new version Execute the following in ij: UPDATE TEST SET INFO = 1 WHERE TESTID = 2; ERROR 54038: Maximum depth of nested triggers was exceeded. Note: This issue stemmed from the Invalid issue, DERBY-1603, because a user hit the exception after upgrade and thought the exception after upgrade, not the lack of exception before upgrade was the problem. This may be a common user error, so we need a release note to help mitigate the issue.I will add one shortly after confirming the correct trigger syntax. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1057) documentation to address Grant/Revoke (Derby-464)
[ http://issues.apache.org/jira/browse/DERBY-1057?page=comments#action_12428224 ] Jean T. Anderson commented on DERBY-1057: - Committed patch derby1057_ref4.diff revision 431700. documentation to address Grant/Revoke (Derby-464) - Key: DERBY-1057 URL: http://issues.apache.org/jira/browse/DERBY-1057 Project: Derby Issue Type: Sub-task Components: Documentation Affects Versions: 10.0.2.0 Reporter: Eric Radzinski Assigned To: Laura Stewart Fix For: 10.2.0.0 Attachments: derby1057_devguide.diff, derby1057_devguide3.diff, derby1057_devguide4.ddiff, derby1057_devguide_html.zip, derby1057_devguide_html3.zip, derby1057_devguide_html4.zip, derby1057_ref.diff, derby1057_ref3.diff, derby1057_ref4.diff, derby1057_ref_html.zip, derby1057_ref_html4.zip, derby1057_tuning3.diff, derby1057_tuning4.diff, derby1057_tuning_html.zip, derby1058_ref_html3.zip, devguide_html2.zip, ref_html2.zip, rtunpropersqlauth.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: [junit] Move JUnit base/utility classes???
Sounds good to me... David Daniel John Debrunner wrote: Currently the JUnit base and utility classes are in this package: org.apache.derbyTesting.functionTests.util (See http://wiki.apache.org/db-derby/DerbyJUnitTesting) I was wondering if they should be moved, for two reasons: 1) That package is cluttered up with other stuff, it's more or less a dumping ground. Utilites, JUnit base classes, user level classes for procedures and vtis, etc. 2) JUnit tests can be much more than funcional tests, e.g. having system tests as JUnit tests would make them easy for everyone to run. I was thinking of the following package: org.apache.derbyTesting.junit The package would be limited to base classes for JUnit tests and JUnit related utilities such as the JDBC class. Classes for specific tests, or those that implement Java procedures for tests etc. would not be allowed. The functional tests would continue to live in their current location, just that the super-class BaseJDBCTestCase would be in the new package. Thoughts? Dan.
[jira] Assigned: (DERBY-1570) The derby configuration, logging and diagnostic properties such as derby.language.logStatementText are hard to find in the documentation
[ http://issues.apache.org/jira/browse/DERBY-1570?page=all ] Laura Stewart reassigned DERBY-1570: Assignee: Laura Stewart The derby configuration, logging and diagnostic properties such as derby.language.logStatementText are hard to find in the documentation - Key: DERBY-1570 URL: http://issues.apache.org/jira/browse/DERBY-1570 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.1.2.1 Reporter: Kathey Marsden Assigned To: Laura Stewart Priority: Minor I often see questions like How do I turn on logging or tracing for Derby. I want to log statements or locks, query plans or something else. This came up on derby-user on this thread: http://www.nabble.com/Logging-tf1981511.html Unfortunately the documentation for Derby properties does not give a hit on logging or tracing, diagnostics, configuration, or trace, Maybe these properties could be presented better in the documentation and a diagnostics section would be most helpful but a quick fix for 10.2 might be to add a sentence with the key words to. http://db.apache.org/derby/docs/10.1/tuning/ctunproper22250.html Instead of This chapter includes all the core Derby properties. We could have. This chapter includes all the core Derby properties. The Derby properties are used for system and database configuration as well as diagnostics such as logging statements, and monitoring and tracing locks. That would give us hits on the important key words. -- 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-1691) jdbcapi/blobclob4BLOB.java fails under DerbyNet framework with JCC 2.6
I reran the tests and got the same diffs, so I applied the changes and committed. I suspect we have a version difference between the JCC drivers that I have been running and what is used in the regression tests. David Craig Russell (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1691?page=comments#action_12428209 ] Craig Russell commented on DERBY-1691: -- There is a tiny difference in the message text for: com.ibm.db2.jcc.c.SqlException com.ibm.db2.jcc.a.SqlException Is the difference something needs to be explained? Craig jdbcapi/blobclob4BLOB.java fails under DerbyNet framework with JCC 2.6 -- Key: DERBY-1691 URL: http://issues.apache.org/jira/browse/DERBY-1691 Project: Derby Issue Type: Bug Components: Test, Regression Test Failure Affects Versions: 10.2.0.0 Environment: Linux 2.6.9-5.ELsmp Sun jdk 1.5.0_07-b03 Reporter: Rajesh Kartha Assigned To: David Van Couvering Fix For: 10.2.0.0 With JCC 2.6, the jdbcapi/blobclob4BLOB.java fails. The diff did not show anything alarming, so I am guessing it may be a master update. The test passed fine with DerbyClient *** Start: blobclob4BLOB jdk1.5.0_06 DerbyNet derbynetmats:jdbcapi 2006-08-11 23:29:48 *** 466a467,474 EXPECTED SQLSTATE(22018): Invalid character string format for type INTEGER. end clobTest54 START: clobTest6 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 FAIL -- unexpected exception:java.lang.StringIndexOutOfBoundsException: String index out of range: -1 468,475d475 EXPECTED SQLSTATE(22018): Invalid character string format for type INTEGER. end clobTest54 START: clobTest6 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 FAIL -- unexpected exception:java.lang.StringIndexOutOfBoundsException: String index out of range: -1 775a776,782 blobTest54 finished START: blobTest6 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 FAIL -- unexpected exception:java.lang.NegativeArraySizeException 777,783d783 blobTest54 finished START: blobTest6 EXPECTED SQLSTATE(null): Invalid position 0 or length 5 EXPECTED SQLSTATE(null): Invalid position 1 or length -76 EXPECTED SQLSTATE(null): Invalid position 1 or length -1 EXPECTED SQLSTATE(null): Invalid position 0 or length 0 FAIL -- unexpected exception:java.lang.NegativeArraySizeException 789 del com.ibm.db2.jcc.c.SqlException: Operation 'CREATE TRIGGER' cannot be performed on object 'TESTBLOB' because there is an open ResultSet dependent on that object. 789a789 com.ibm.db2.jcc.a.SqlException: Operation 'CREATE TRIGGER' cannot be performed on object 'TESTBLOB' because there is an open ResultSet dependent on that object. Test Failed. *** End: blobclob4BLOB jdk1.5.0_06 DerbyNet derbynetmats:jdbcapi 2006-08-11 23:30:46 ***
Re: DERBY-1057 : patch Derby1057_ref4.diff and a G svn status
Jean T. Anderson wrote: Applying derby1057_ref4.diff gets Reversed (or previously applied) patch detected! Assume -R? so I did this trick: svn up -r 431389 patch -p0 -i derby1057_ref4.diff svn up 'svn status' shows everything looks good except for the ditamap file: G src/ref/refderby.ditamap I'm looking for info about that G status and am not finding it at http://svnbook.red-bean.com/en/1.0/re26.html , but I vaguely recall from other ASF projects that it means something about local modifications colliding with what is checked into the server. The doc build succeeds. Is it safe to just go ahead and commit this? Yes, the G stands for merged. http://svnbook.red-bean.com/en/1.2/svn.tour.cycle.html#svn.tour.cycle.examine.status Andreas thanks, -jean
Re: DERBY-1057 : patch Derby1057_ref4.diff and a G svn status
Andreas Korneliussen wrote: Jean T. Anderson wrote: ... 'svn status' shows everything looks good except for the ditamap file: G src/ref/refderby.ditamap I'm looking for info about that G status and am not finding it at http://svnbook.red-bean.com/en/1.0/re26.html , but I vaguely recall from other ASF projects that it means something about local modifications colliding with what is checked into the server. The doc build succeeds. Is it safe to just go ahead and commit this? Yes, the G stands for merged. http://svnbook.red-bean.com/en/1.2/svn.tour.cycle.html#svn.tour.cycle.examine.status Oh good -- a C would be a problem but G and U are ok. Thanks for the URL, Andreas, -jean
[jira] Assigned: (DERBY-931) Until Derby-911 gets fixed, document the difference in behavior between Nework Client Driver and Embedded Driver for setReadOnly
[ http://issues.apache.org/jira/browse/DERBY-931?page=all ] Laura Stewart reassigned DERBY-931: --- Assignee: Laura Stewart Until Derby-911 gets fixed, document the difference in behavior between Nework Client Driver and Embedded Driver for setReadOnly Key: DERBY-931 URL: http://issues.apache.org/jira/browse/DERBY-931 Project: Derby Issue Type: Sub-task Components: Documentation Affects Versions: 10.0.2.1 Reporter: Mamta A. Satoor Assigned To: Laura Stewart Derby 911 Connection.setReadOnly is a no-op in Network Client. It works fine with embedded client. has more details on this issue but basically, we should document the difference in behavior for setReadOnly between Network Driver and Embedded Driver. -- 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-1636) document encryption of an un-encrypted database and re-encryption with new password/key.
Thanks for volunteering to document this Laura. Laura Stewart (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1636?page=comments#action_12428222 ] Laura Stewart commented on DERBY-1636: -- The spec indicates that the newEncryptionKey attribute should be used with the encryptionKey attribute. I don't see the encryptionKey attribute documented in the Derby docs... anywhere. Can you please check on this? Thanks for volunteering to write the documentation, Laura. You are right, documentation about encrypting a database using an external encryption Key attribute is missing. Sunitha filed a Jira for this issue: https://issues.apache.org/jira/browse/DERBY-1622 It would be great, if you could document derby-1622 also. Thanks -suresh
Re: some minor doc warnings on the truk...
Army wrote: Suresh Thalamati wrote: [javadoc] C:\nightlies\main\src\opensource\java\engine\org\apache\derby\iapi\types\XML.java:262: warning - Tag @see: can't find setFrom org.apache.derby.iapi.types.DataValueDescriptor [javadoc] C:\nightlies\main\src\opensource\java\engine\org\apache\derby\iapi\types\XML.java:163: warning - @param argument qualXType is not a parameter name. Attached patch should fix these two javadoc errors in XML.java. Thanks for catching these, Suresh. Army Thanks Army. I will commit the patch. -suresh
[jira] Updated: (DERBY-1692) Client driver does not use the query timeout value set using Statement.setQueryTimeout() for subsequent executions using the same statement object
[ http://issues.apache.org/jira/browse/DERBY-1692?page=all ] Knut Anders Hatlen updated DERBY-1692: -- Component/s: (was: Network Server) Derby Info: [Patch Available] Client driver does not use the query timeout value set using Statement.setQueryTimeout() for subsequent executions using the same statement object -- Key: DERBY-1692 URL: http://issues.apache.org/jira/browse/DERBY-1692 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.2.0.0, 10.3.0.0 Reporter: Deepa Remesh Assigned To: Knut Anders Hatlen Attachments: derby-1692-tests.diff, derby-1692-tests.stat, derby-1692.diff, TestQueryTimeout.java I will attach a repro with more details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
