[jira] Closed: (DERBY-463) Successive writes to a java.sql.Blob.setBinaryStream(long) seem to reset the file pointer

[ http://issues.apache.org/jira/browse/DERBY-463?page=all ] Fernanda Pizzorno closed DERBY-463: --- Successive writes to a java.sql.Blob.setBinaryStream(long) seem to reset the file pointer

[jira] Resolved: (DERBY-463) Successive writes to a java.sql.Blob.setBinaryStream(long) seem to reset the file pointer

[ http://issues.apache.org/jira/browse/DERBY-463?page=all ] Fernanda Pizzorno resolved DERBY-463: - Resolution: Fixed Successive writes to a java.sql.Blob.setBinaryStream(long) seem to reset the file pointer

Re: [Db-derby Wiki] Update of DerbyDevActivities by SatheeshBandaram

Daniel John Debrunner wrote (2006-01-12 09:06:20): Bernt M. Johnsen wrote: BUT: I think its equally (or more) important that we take full advantage of Jira too. The most important one is to set Jira issues being worked on to In progress. In an open source project is there any

[jira] Commented: (DERBY-788) 'store/encryptionKey.sql' fails on Solaris 10

[ http://issues.apache.org/jira/browse/DERBY-788?page=comments#action_12362838 ] Kristian Waagan commented on DERBY-788: --- I got a response to my inquiry about this issue: ...it is not clearly defined how SecretKeyFactories and Ciphers behave when

Re: Making contributions to individuals on the list is not recommended

Jean T. Anderson [EMAIL PROTECTED] wrote: Actually, what I realize is the best way to handle this is for the author of a presentation to upload it to the ApacheCon wiki: http://wiki.apache.org/apachecon/Us2005OnlineSessionSlides Olav, could you go ahead and upload your presentation to

[jira] Commented: (DERBY-796) jdbc 4.0 specific Blob and Clob method support

[ http://issues.apache.org/jira/browse/DERBY-796?page=comments#action_12362846 ] Rick Hillegas commented on DERBY-796: - The code looks fine. Now derbyall passes cleanly. Also, the jdbc4 tests run cleanly on jdk1.6. I recommend that this patch be

[jira] Created: (DERBY-814) Prevent unneeded object creation and excessive decoding in parsePKGNAMCSN()

Prevent unneeded object creation and excessive decoding in parsePKGNAMCSN() --- Key: DERBY-814 URL: http://issues.apache.org/jira/browse/DERBY-814 Project: Derby Type: Sub-task Components:

[jira] Created: (DERBY-815) Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()

Prevent unneeded object creation and excessive decoding in parseSQLDTA_work() -- Key: DERBY-815 URL: http://issues.apache.org/jira/browse/DERBY-815 Project: Derby Type: Sub-task

[jira] Updated: (DERBY-815) Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()

[ http://issues.apache.org/jira/browse/DERBY-815?page=all ] Knut Anders Hatlen updated DERBY-815: - Component: Network Server Performance Fix Version: 10.2.0.0 Description: Reported by Kathey Marsden in DERBY-212: In

[jira] Created: (DERBY-816) In DDMWriter and DDMReader, use system routines in java.util.Arrays and System.arrayCopy

In DDMWriter and DDMReader, use system routines in java.util.Arrays and System.arrayCopy Key: DERBY-816 URL: http://issues.apache.org/jira/browse/DERBY-816 Project: Derby Type:

[jira] Closed: (DERBY-814) Prevent unneeded object creation and excessive decoding in parsePKGNAMCSN()

[ http://issues.apache.org/jira/browse/DERBY-814?page=all ] Knut Anders Hatlen closed DERBY-814: Resolution: Fixed Fixed in revision 368333. Prevent unneeded object creation and excessive decoding in parsePKGNAMCSN()

[jira] Updated: (DERBY-816) In DDMWriter and DDMReader, use system routines in java.util.Arrays and System.arrayCopy

[ http://issues.apache.org/jira/browse/DERBY-816?page=all ] Knut Anders Hatlen updated DERBY-816: - Component: Network Server Newcomer Performance Priority: Trivial (was: Minor) It seems like System.arraycopy is

[jira] Commented: (DERBY-810) intermittent diff for store/RecoveryAfterBackup.java test

[ http://issues.apache.org/jira/browse/DERBY-810?page=comments#action_12362855 ] Øystein Grøvlen commented on DERBY-810: --- Thanks, Suresh for the analysis. I think you are right that the reason for the failure is that output to stdout and stderr gets

Re: [jira] Updated: (DERBY-816) In DDMWriter and DDMReader, use system routines in java.util.Arrays and System.arrayCopy

Knut Anders Hatlen (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-816?page=all ] I believe there are also some places in the client code where it could be beneficial to use System.arraycopy and/or Arrays.fill. For example, in Reply.compressBLayerData() in Reply.java there is

[jira] Commented: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.

[ http://issues.apache.org/jira/browse/DERBY-125?page=comments#action_12362858 ] Dyre Tjeldvoll commented on DERBY-125: -- Hi Bryan, I finally had a chance to look through your proposal (I have not yet looked at the actual patch), as I promised to do

[jira] Commented: (DERBY-796) jdbc 4.0 specific Blob and Clob method support

[ http://issues.apache.org/jira/browse/DERBY-796?page=comments#action_12362860 ] Daniel John Debrunner commented on DERBY-796: - The patch lacks comments, the methods that have changed from being not implemented have no java doc or comments.

Re: [jira] Commented: (DERBY-326) Improve streaming of large objects for network server and client

TomohitoNakayama wrote: 3) Code Formatting - There seem to be code indentation inconsistencies in DDMWriter. Also I think it is good to indent the method bodies in the new methods in ReEncodedInputStream.java. Things sort of run together. Reading comments from others, I think a patch

[jira] Commented: (DERBY-326) Improve streaming of large objects for network server and client

[ http://issues.apache.org/jira/browse/DERBY-326?page=comments#action_12362861 ] Kathey Marsden commented on DERBY-326: -- I think this patch is a big improvement over reading the lobs into memory. A few comments on future improvement and some questions

Re: Server and client compatibility test for 10.2 and 10.1

Ramandeep Kaur wrote: Server: 10.2, Client: 10.1, derbyTesting.jar: 10.1 - jvms: jdk15, ibm142 Test failures: derbynetclientmats/derbynetmats/derbynetmats.fail:derbynet/NSinSameJVM.java

[jira] Commented: (DERBY-796) jdbc 4.0 specific Blob and Clob method support

[ http://issues.apache.org/jira/browse/DERBY-796?page=comments#action_12362863 ] Daniel John Debrunner commented on DERBY-796: - After looking a little more, currently setBinaryStreamInternal is not suitable, though it should be! Also looking at

Re: [jira] Updated: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed

On 1/15/06, Bryan Pendleton [EMAIL PROTECTED] wrote: Deepa Remesh (JIRA) wrote: I have attached a partial patch 'derby-210-patch1.diff' for this problem. Hello Deepa, I was interested to read your patch because I have been trying to learn how the client code works. Thanks Bryan for

[jira] Commented: (DERBY-796) jdbc 4.0 specific Blob and Clob method support

[ http://issues.apache.org/jira/browse/DERBY-796?page=comments#action_12362867 ] Sunitha Kambhampati commented on DERBY-796: --- I actually have a patch to fix Derby-599, where I am changing the setBlob(int,Blob) to pass the length as is done in

[jira] Updated: (DERBY-808) PreparedStatements can take longer to execute than Statements. There seem to be a problem with searchClauseTransitiveClosure method in PredicateList.java

[ http://issues.apache.org/jira/browse/DERBY-808?page=all ] Satheesh Bandaram updated DERBY-808: Attachment: DERBY-808.patch Will commit this patch later in the day. Passed all tests, except for intermittent readlocks failure. PreparedStatements

[jira] Commented: (DERBY-326) Improve streaming of large objects for network server and client

[ http://issues.apache.org/jira/browse/DERBY-326?page=comments#action_12362871 ] Kathey Marsden commented on DERBY-326: -- Sorry, one more question. Could you explain the error handling in the new scheme? The old code would call padScalarStreamForError

[jira] Updated: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed

[ http://issues.apache.org/jira/browse/DERBY-210?page=all ] Deepa Remesh updated DERBY-210: --- Attachment: (was: derby-210-patch1.diff) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed

[jira] Updated: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed

[ http://issues.apache.org/jira/browse/DERBY-210?page=all ] Deepa Remesh updated DERBY-210: --- Attachment: (was: derby-210-patch1.status) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed

[jira] Commented: (DERBY-808) PreparedStatements can take longer to execute than Statements. There seem to be a problem with searchClauseTransitiveClosure method in PredicateList.java

[ http://issues.apache.org/jira/browse/DERBY-808?page=comments#action_12362872 ] Satheesh Bandaram commented on DERBY-808: - I will try to create a test case for this issue, which may need some actual data to show this optimizer issue. I may not be

[jira] Updated: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed

[ http://issues.apache.org/jira/browse/DERBY-210?page=all ] Deepa Remesh updated DERBY-210: --- Attachment: derby-210.diff derby-210.status I am uploading a combined patch 'derby-210.diff' which solves the memory leak. As Bryan suggested, I

Re: [Db-derby Wiki] Update of DerbyDevActivities by SatheeshBandaram

One of the issues I see is that 'In progress' doesn't indicate when the feature/bug might be addressed. This makes it hard to plan and drive to a release, especially with partial checkin model being followed. Just my concerns. Satheesh Bernt M. Johnsen wrote: Well, first of all. Jira has a nice

Re: [Db-derby Wiki] Update of DerbyDevActivities by SatheeshBandaram

Satheesh Bandaram wrote: One of the issues I see is that 'In progress' doesn't indicate when the feature/bug might be addressed. This makes it hard to plan and drive to a release, especially with partial checkin model being followed. Just my concerns. Jira also has a Due Date field which

Re: Grant and Revoke, Part I ... DERBY-464...

Daniel John Debrunner wrote: Satheesh Bandaram wrote I think mixing both will lead to confusion to users many already familiar with the ansi subset model being proposed. This will also create hurdles as we expand authorization scheme to support roles and "system privileges" as

[jira] Commented: (DERBY-170) Inserting large string value into non-existent table causes communication link failure over Network Server.

[ http://issues.apache.org/jira/browse/DERBY-170?page=comments#action_12362883 ] Kathey Marsden commented on DERBY-170: -- I checked in this change. Thanks Bryan for the patch. Date: Mon Jan 16 11:19:26 2006 New Revision: 369549 URL:

Re: Grant and Revoke, Part I ... DERBY-464...

Satheesh Bandaram wrote: If we are proposing combining both authorization models, why not go the whole way and say Grant/Revoke is always enabled in a 10.2 database? If applications want to keep their current authorization model, they don't need to use new fine-grained access control allowed

Re: Activation re-using language ResultSets performance gain

This does looks like a great optimization. It would be good to have an Improvement item filed with your Activation change. People can investigate individual failures and post their fixes to ResultSet implementations. I would like to help address some of the resultset changes. Satheesh Daniel

Re: [jira] Commented: (DERBY-170) Inserting large string value into non-existent table causes communication link failure over Network Server.

Bryan, it's very impressive the information you provide with your changes. I am wondering if changes.html gets checked into the codeline somewhere or does it stay in the JIRA entry for future reference? Mamta On 1/16/06, Kathey Marsden (JIRA) derby-dev@db.apache.org wrote: [

Re: [jira] Updated: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed

Deepa Remesh (JIRA) derby-dev@db.apache.org writes: * Adds a test 'derbyStress.java' to jdbcapi suite. This test is based on the repro for this patch. Without this patch, it fails when run with client driver. Kathey had suggested in another mail that tests for client memory leak problems

Re: VTI, Indexed Lookup and the Query Optimizer

Army wrote: This method is called from the feasible() methods of both NestedLoopJoinStrategy.java and HashJoinStrategy.java. In the latter case, if this method returns false, the optimizer won't ever try to do a hash join (at least, that's how I read the code). So if we have a subquery,

[jira] Created: (DERBY-817) Improvements to Network Client driver - analyze/improve use of java collection classes in the code

Improvements to Network Client driver - analyze/improve use of java collection classes in the code -- Key: DERBY-817 URL: http://issues.apache.org/jira/browse/DERBY-817 Project:

Re: Server and client compatibility test for 10.2 and 10.1

Ramandeep Kaur wrote: Thanks to Kathey for looking into test failures. Attaching tmp and tmpstr files for autoGeneratedJdbc30 and holdCursorJDBC30. Please check out the attachments. These do not look like compatibility problems. holdCursorJDBC30 - Output changed with fix for DERBY-213

Re: [jira] Commented: (DERBY-298) rollforward will not work correctly if the system happens to crash immediately after rollforward backup.

DJD( == Daniel John Debrunner (JIRA) derby-dev@db.apache.org writes: DJD( This patch added two new tests, RecoveryAfterBackup and DJD( RecoveryAfterBackupSetup, both of which are being run DJD( without a SecurityManager due to the noSecurityManager=true DJD( in their

[jira] Commented: (DERBY-353) It is desirable to have IDENTITY_VAL_LOCAL() function return last recent user specified value or system generated value for BY DEFAULT identity columns.

[ http://issues.apache.org/jira/browse/DERBY-353?page=comments#action_12362891 ] Kathey Marsden commented on DERBY-353: -- In looking at the master for autogeneratedJdbc30, I noticed that although the master was updated with this fix to reflect the new

Re: VTI, Indexed Lookup and the Query Optimizer

Satheesh Bandaram wrote: Army wrote: So if we have a subquery, in which case childResult will (or least can) be a SelectNode, the fact that SelectNode is NOT an instance of Optimizable means that this method will return false and the optimizer won't ever consider a hash join when the inner

Re: Grant and Revoke, Part I ... DERBY-464...

Francois Orsini wrote: Yes and I will be posting more details very soon. Great... Would love to see more details. If we are proposing combining both authorization models, why not go the whole way and say Grant/Revoke is always enabled in a 10.2 database? If

Re: Server and client compatibility test for 10.2 and 10.1

On 1/16/06, Kathey Marsden [EMAIL PROTECTED] wrote: Ramandeep Kaur wrote:Thanks to Kathey for looking into test failures.Attaching tmp and tmpstr files for autoGeneratedJdbc30 and holdCursorJDBC30. Please check out the attachments.These do not look like compatibility problems.holdCursorJDBC30 -

Re: VTI, Indexed Lookup and the Query Optimizer

That said, it seems reasonable to think that the optimizer should at least consider doing a hash join on the subquery, in which case the join between T2 and T3 could be materialized and then a hash-join could be done using the predicate x1.j = t1.i. I think the best thing would be to

[jira] Commented: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.

[ http://issues.apache.org/jira/browse/DERBY-125?page=comments#action_12362895 ] Kathey Marsden commented on DERBY-125: -- Hi Bryan Thank you so much again for your excellent documentation. I am learning quite a bit and appreciate your very high

[jira] Commented: (DERBY-808) PreparedStatements can take longer to execute than Statements. There seem to be a problem with searchClauseTransitiveClosure method in PredicateList.java

[ http://issues.apache.org/jira/browse/DERBY-808?page=comments#action_12362897 ] Satheesh Bandaram commented on DERBY-808: - Submitted fix to 10.1 branch. Sendingjava\engine\org\apache\derby\impl\sql\compile\PredicateList.java Transmitting

Re: VTI, Indexed Lookup and the Query Optimizer

Jeffrey Lichtman wrote: That said, it seems reasonable to think that the optimizer should at least consider doing a hash join on the subquery, in which case the join between T2 and T3 could be materialized and then a hash-join could be done using the predicate x1.j = t1.i. I think the best

[jira] Commented: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed

[ http://issues.apache.org/jira/browse/DERBY-210?page=comments#action_12362900 ] Kathey Marsden commented on DERBY-210: -- Committed this patch. Date: Mon Jan 16 16:10:58 2006 New Revision: 369612 URL: http://svn.apache.org/viewcvs?rev=369612view=rev

[jira] Commented: (DERBY-817) Improvements to Network Client driver - analyze/improve use of java collection classes in the code

[ http://issues.apache.org/jira/browse/DERBY-817?page=comments#action_12362901 ] Kathey Marsden commented on DERBY-817: -- One additional thing that I noticed in reviewing the patch for DERBY-210 was that Connection.java had this comment which to the

[jira] Created: (DERBY-818) Read-only embedded ResultSets incur performance penalty due to updateable ResultSet code.

Read-only embedded ResultSets incur performance penalty due to updateable ResultSet code. - Key: DERBY-818 URL: http://issues.apache.org/jira/browse/DERBY-818 Project: Derby

[jira] Updated: (DERBY-818) Read-only embedded ResultSets incur performance penalty due to updateable ResultSet code.

[ http://issues.apache.org/jira/browse/DERBY-818?page=all ] Daniel John Debrunner updated DERBY-818: Attachment: derby818patch.txt This patch addresses the issue by: 1) Only allocating the arrays if the ResultSet is updateable 2) Only reseting

Re: VTI, Indexed Lookup and the Query Optimizer

Based on logic in the code, the example query isn't flattenable. . . That's because whoever wrote the code made it handle only the simplest case. I doubt it would be hard to make it flatten many other types of table subqueries. My general philosophy toward query performance issues is that

[jira] Commented: (DERBY-573) Provide support for optimizer overrides in Derby.

[ http://issues.apache.org/jira/browse/DERBY-573?page=comments#action_12362904 ] Satheesh Bandaram commented on DERBY-573: - I have submitted this fix to trunk. Thanks for enhancing RUNSTATs to show user specified optimizer hints are being used!

Re: [PATCH](DERBY-783) Enhance ALTER TABLE syntax to allow users to change the next value to be generated for an identity column

Hi Mamta, Since I applied your other patch, this patch can't be applied as is. (since they share some of the same files) Can you update your patch and post it, please? Satheesh Mamta Satoor wrote: Posted this few days back. Anyone has comments? Thanks, Mamta On 1/3/06, Mamta

documenting GRANT/REVOKE

I'd like to take a shot at documenting GRANT/REVOKE. This particular question pertains to adding these statements to the Derby Reference Manual: Would it be better to document each statement in just two separate topics one for GRANT and another for REVOKE), or should there be separate topics

[jira] Updated: (DERBY-239) Need a online backup feature that does not block update operations when online backup is in progress.

[ http://issues.apache.org/jira/browse/DERBY-239?page=all ] Suresh Thalamati updated DERBY-239: --- Attachment: onlinebackup_7.diff This patch addresses the issues raised by Øystein in his review of previous online backup patches 3-6. - changed the

Re: [jira] Commented: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed

Thanks Kathey for looking at the patch. I don't see any issues in porting this fix to 10.1. I will run tests with 10.1 and post the merge command. Thanks, Deepa

[jira] Commented: (DERBY-818) Read-only embedded ResultSets incur performance penalty due to updateable ResultSet code.

[ http://issues.apache.org/jira/browse/DERBY-818?page=comments#action_12362911 ] Mamta A. Satoor commented on DERBY-818: --- I looked through the changes and they look good. I should have been more cautious when I originally wrote this code. Read-only

Re: [PATCH](DERBY-783) Enhance ALTER TABLE syntax to allow users to change the next value to be generated for an identity column

Hi Satheesh, Thanks for looking into committing this patch. I have done a sync on my client and will look into resolving the conflicts. After that, Iwant to rerun all the tests before submitting an updated patch. Mamta On 1/16/06, Satheesh Bandaram [EMAIL PROTECTED] wrote: Hi Mamta,Since I

[jira] Commented: (DERBY-486) Fix Error message X0X07 in doc to match string changes in code

[ http://issues.apache.org/jira/browse/DERBY-486?page=comments#action_12362914 ] Jeff Levitt commented on DERBY-486: --- The patch looks good to me; the changes bring the error message text in the doc in line with the code change. I recommend a commit.

[jira] Updated: (DERBY-326) Improve streaming of large objects for network server and client

[ http://issues.apache.org/jira/browse/DERBY-326?page=all ] Sunitha Kambhampati updated DERBY-326: -- Attachment: ClobTest.zip Thanks Tomohito for the patch. I wanted to try a simple clob test with reads and see if there was any difference