db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3898) Blob.setBytes differs between embedded and client driver when the specified length is invalid
Date Tue, 13 Jul 2010 12:10:49 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12887727#action_12887727
] 

Kristian Waagan commented on DERBY-3898:
----------------------------------------

Hi Yun,

I'm really not sure what to say here. Both approaches have merit:
 o ArrayIndexOutOfBounds : well known pattern from Java, may simplify the input validation
code in Derby
 o SQLException : follows JDBC pattern, higher chance that the exception will be caught and
dealt with

Since the problem in this case isn't really database related, I'm leaning towards AIOOB (as
Dag commented too). Funnily enough, the embedded driver is throwing an SQLException, catching
it and then throwing an AIOOB.
If anyone else has opinions it would be nice if you share them now such that we can allow
Yun to continue work on this issue.

When it comes to the test code, I have the following comments:
 a) I don't see the point of statements like 'assertTrue(true)'. Why not simply add a comment?
 b) For tests like the one below, you should add a fail() statement in case the setBytes-method
doesn't throw an exception.

+        try {
+            blob.setBytes(1, new byte[] {0xb}, -1, 1);
+        } catch (SQLException sqle) {
+            assertSQLState("XJ078", sqle);
+        }

 c) If the tests don't use any API methods from JDBC 4, we usually add them to jdbcapi instead
of jdbc4. That way, the tests are run also when the JDK version is 1.4 or 1.5. Are there any
suitable existing test classes in jdbcapi?

I think the problems you had with NoSuchMethod errors were caused by a bad build. Some times
it is good to run 'ant clobber' (or 'ant clobber all buildjars') to recompile all classes.


Thanks,

> Blob.setBytes differs between embedded and client driver when the specified length is
invalid
> ---------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3898
>                 URL: https://issues.apache.org/jira/browse/DERBY-3898
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.3.3.0, 10.4.2.0, 10.5.1.1, 10.6.1.0
>            Reporter: Kristian Waagan
>            Assignee: Yun Lee
>            Priority: Minor
>         Attachments: derby-3898-testcase.patch, derby-3898-testcase.stat, Derby3898.java
>
>
> Blob.setBytes behaves differently with the embedded driver and the client driver.
> Assume a 1 byte array and a specified length of 2: Blob.setBytes(1, new byte[] {0x69},
0, 2)
> Embedded: IndexOutOfBoundsException (from java.io.RandomAccessFile.writeBytes or System.arraycopy)
> Client: succeeds, returns insertion count 1
> The behavior should be made consistent, but what is the correct behavior?
> From the Blob.setBytes JavaDoc:
> "Writes all or part of the given byte array to the BLOB value that this Blob object represents
and returns the number of bytes written. Writing starts at position pos in the BLOB  value;
len bytes from the given byte array are written. The array of bytes will overwrite the existing
bytes in the Blob object starting at the position pos. If the end of the Blob value is reached
while writing the array of bytes, then the length of the Blob value will be increased to accomodate
the extra bytes."

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message