Return-Path: X-Original-To: apmail-db-derby-dev-archive@www.apache.org Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id CC3E3FB66 for ; Sun, 2 Jun 2013 01:27:22 +0000 (UTC) Received: (qmail 39024 invoked by uid 500); 2 Jun 2013 01:25:16 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 32607 invoked by uid 500); 2 Jun 2013 01:24:45 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 2025 invoked by uid 99); 1 Jun 2013 21:29:19 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 01 Jun 2013 21:29:19 +0000 Date: Sat, 1 Jun 2013 21:29:19 +0000 (UTC) From: "Mamta A. Satoor (JIRA)" To: derby-dev@db.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (DERBY-6237) PreparedStatement.execute() fails starting 10.2 when multiple rows are updated and PreparedStatement.setCharacterStream(int, Reader, int) is used MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/DERBY-6237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13672219#comment-13672219 ] Mamta A. Satoor edited comment on DERBY-6237 at 6/1/13 9:27 PM: ---------------------------------------------------------------- Commited a test into 10.2 with revisions 1488453 and 1488606. There are 2 test one for testing setCharacterStream on CLOB and other for testing setCharacterStream on VARCHAR column. This way failure of one data type will not mask the behavior of the other data type. I found through this test sparation that in 10.2, 1)setCharacterStream on VARCHAR columns work fine(just like 10.1 release) for both one row and multi-row update through prepared statement. 2)But setCharacterStream on CLOB column when update touches more than one row(in case of embedded only) fails in 10.2 release. was (Author: mamtas): Commited a test into 10.2 with revision 1488453 with following comments *********************************************** This commit adds test case for updating more than one row with setCharacterStream to update VARCHAR column in the underlying table. The test is commented out at this point since it does not work in 10.2. Once this jira is fixed in 10.2, we should uncomment these tests. This test case works fine in 10.1 *********************************************** > PreparedStatement.execute() fails starting 10.2 when multiple rows are updated and PreparedStatement.setCharacterStream(int, Reader, int) is used > ------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: DERBY-6237 > URL: https://issues.apache.org/jira/browse/DERBY-6237 > Project: Derby > Issue Type: Bug > Components: JDBC > Affects Versions: 10.2.2.1, 10.3.3.1, 10.4.2.1 > Reporter: Mamta A. Satoor > > PreparedStatement.execute() worked on 10.1(both embedded and network server) when multiple rows are updated and PreparedStatement.setCharacterStream(int, Reader, int) is used. In 10.2, the embedded case stopped working for multi-row update using a prepared statement which used PreparedStatement.setCharacterStream(int, Reader, int) with exception > java.io.EOFException: Stream has already been read and end-of-file reached and cannot be re-used. > at org.apache.derby.iapi.types.ReaderToUTF8Stream.read(ReaderToUTF8Stream.java:185) > at org.apache.derby.impl.store.raw.data.MemByteHolder.write(MemByteHolder.java:146) > at org.apache.derby.impl.store.raw.data.RememberBytesInputStream.fillBuf(RememberBytesInputStream.java:135) > at org.apache.derby.impl.store.raw.data.StoredPage.logColumn(StoredPage.java:6167) > at org.apache.derby.impl.store.raw.data.StoredPage.logRow(StoredPage.java:3971) > at org.apache.derby.impl.store.raw.data.UpdateOperation.writeOptionalDataToBuffer(UpdateOperation.java:255) > at org.apache.derby.impl.store.raw.data.UpdateOperation.(UpdateOperation.java:106) > at org.apache.derby.impl.store.raw.data.LoggableActions.actionUpdate(LoggableActions.java:80) > at org.apache.derby.impl.store.raw.data.StoredPage.doUpdateAtSlot(StoredPage.java:8549) > at org.apache.derby.impl.store.raw.data.BasePage.updateAtSlot(BasePage.java:1178) > at org.apache.derby.impl.store.access.conglomerate.GenericConglomerateController.replace(GenericConglomerateController.java:479) > at org.apache.derby.impl.sql.execute.RowChangerImpl.updateRow(RowChangerImpl.java:523) > at org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(UpdateResultSet.java:579) > at org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:273) > at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:358) > at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1182) > at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1635) > at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(EmbedPreparedStatement.java:1304) > at org.apache.derbyTesting.functionTests.tests.lang.MamtaJDBC.main(MamtaJDBC.java:91) > In 10.3 and 10.4, both the embedded and network server cases are broken for multi-row update using a prepared statement which used PreparedStatement.setCharacterStream(int, Reader, int).I still need to test 10.5 and higher. I will also add junit test cases for each of these releases on incremental basis. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira