[
https://issues.apache.org/jira/browse/DERBY-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680603#comment-13680603
]
Mike Matrigali commented on DERBY-6214:
---------------------------------------
comments on patch and existing test. I think at this point the goal for 6214
is to make setObject work as well as setString, and close out this issue with
the patch. Then address large strings in another issue. To this end:
1) you should change comments in ParameterMappingTest that were written before
the other issues were created. For instance:
"once DERBY-6214 is fixed, we can remove following check".
2) testDerby6214 is hard to understand what is going on. Some comments about
the i,j loop would help. I also would at least rename i to something like
numrows.
helperTest could use more comments also. I think the various cases could
benefit from some comments like "test small string less that critical xxxx
length",
test large string greater than xxx length. The magic numbers for length
come from code path zzz. would be good to define what large string is and
why, maybe a constant with a comment..
3) in CrossConverters.java:
o in comments for setObject i think originalSetObject is false in the case
of setXXX calls that are not setObject, but that is not clear from the comments.
o there is more talk about magic number 32767/3, there should be one
constant with a good name somewhere shared by all the code, and why it is
important.
o it would be nice to fix up comments for setObject that you have added to.
it should start with saying what the routine is doing. Is the following
correct?:
// Convert from string source to target type.
// In support of PS.setXXX, PS.updateXXX, and PS.getXXX
o you added the following with no comment as to why, I would prefer not to
add an extra call level to this high traffic routine if possible. Is it just
to save some
typing to change all the callse in the following setObject routine? If
so I would just rather see the code change made. all the overriding based on
num arguments can
easily lead to bugs when making changes like this, other routine may
start getting called that you don't expect. :
final Object setObject(int targetType, Object source) throws SqlException {
return setObject(targetType, source, false);
}
4) what problems result if you don't have the originalSetObject information?
It would be better if we did not have the special case if we can help it, just
always send string in small string case.
It seems likely there are existing problems with updateXXX also. maybe
just is not right for getXXX, not sure. I'd like to see if there is any way to
fix this without adding a param/extra call to
this high traffic routine.
> PreparedStatement.setObject(int, Object, Types.CLOB) fail with DerbyNet
> -----------------------------------------------------------------------
>
> Key: DERBY-6214
> URL: https://issues.apache.org/jira/browse/DERBY-6214
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.8.3.0, 10.9.1.0
> Reporter: Rong Qu
> Assignee: Mamta A. Satoor
> Attachments: Derby6214.java, DERBY6214_patch1_diff.txt,
> DERBY6214_patch1_stat.txt, Derby6214_setup.sql, Derby6214_ver2.java,
> derby.log, DerbyNet_client_test.sql
>
>
> The issue is specific to the DerbyNet client driver, and doesn't seem to
> occur using embedded Derby.
> "PreparedStatement.setObject(int, Object, Types.CLOB)". It seems to be a
> problem updating a CLOB column with a parameterized value using the DerbyNet
> client driver, and if the update SQL ends up updating more than one row. I
> attached a simple test case that just uses JDBC to reproduce the error. The
> exception looks like this:
> org.apache.derby.client.am.BatchUpdateException: Non-atomic batch failure.
> The batch was submitted, but at least one exception occurred on an individual
> member of the batch. Use getNextException() to retrieve the exceptions for
> specific batched elements.
> at org.apache.derby.client.am.Agent.endBatchedReadChain(Unknown Source)
> at
> org.apache.derby.client.am.PreparedStatement.executeBatchRequestX(Unknown
> Source)
> at org.apache.derby.client.am.PreparedStatement.executeBatchX(Unknown
> Source)
> at org.apache.derby.client.am.PreparedStatement.executeBatch(Unknown
> Source)
> ...
> Caused by: org.apache.derby.client.am.SqlException: Error for batch element
> #0: An unexpected exception was thrown
> at org.apache.derby.client.am.Statement.completeExecute(Unknown Source)
> at
> org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(Unknown
> Source)
> at org.apache.derby.client.net.NetStatementReply.readExecute(Unknown
> Source)
> at org.apache.derby.client.net.StatementReply.readExecute(Unknown Source)
> at org.apache.derby.client.net.NetPreparedStatement.readExecute_(Unknown
> Source)
> at org.apache.derby.client.am.PreparedStatement.readExecute(Unknown
> Source)
> ... 4 more
> Caused by: org.apache.derby.client.am.SqlException: Error for batch element
> #0: Java exception: 'Stream has already been read and end-of-file reached and
> cannot be re-used.: java.io.EOFException'.
> at org.apache.derby.client.am.SqlException.<init>(Unknown Source)
> at org.apache.derby.client.am.SqlException.<init>(Unknown Source)
> ... 10 more
--
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
