[
https://issues.apache.org/jira/browse/DERBY-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701702#action_12701702
]
Kathey Marsden commented on DERBY-2769:
---------------------------------------
Thank you Yun for the new patch.
message change patch DERBY-2769-3-b.diff looks fine. I will run tests and check
that in.
Clob.java
remove import org.apache.derby.impl.jdbc.Util;
This is unused and may bring engine code into the client which is not
good.
For the condition below there are a few issues:
if (offset + len > str.length()) {
throw new SqlException(agent_.logWriter_,
new ClientMessageId(
SQLState.LANG_SUBSTR_START_OR_LEN_OUT_OF_RANGE),
new Integer(offset), new Integer(len));
}
Even though we are sharing a SQLState with
SQLState.LANG_SUBSTR_START_OR_LEN_OUT_OF_RANGE we need a new message, because
the existing one, "The second or third argument of the SUBSTR function is out
of range." doesn't make sense in this context and doesn't take parameters. I
think the way to do this is add a new constant to SQLState.java with value
"22011.S.1", then add that message to messages.xml. The message should be
something like: "The range specified for the substring with offset {0} and len
{1} is not valid". There is another step too when adding SQLState messages to
the client. They have to be added to
java/build/org/apache/derbyBuild/splitmessages.java to get picked up by the
client build. Otherwise it will just print UNKOWN MESSAGE. After making the
changes, you may want to verify them manually or temporarily print out the
message in your JUnit test to make sure it all worked. Unfortunately our JUnit
tests just check SQLState so can miss issues with message te
xt.
ClobTest.java
There is a comment
//if offset + len == str.length(), it's accepted.
I think this is incorrect and the test case below it useds str.length() -1
EmbedClob.java
Again we should use a new message instead of
LANG_SUBSTR_START_OR_LEN_OUT_OF_RANGE
I think the new checking causes some cases that used to execute to now fail
with client. For example I found I could execute setString(1,"goodbye",2,6)
where the offset + len were greater than the length of the string before the
change, but not after. I think the changes are ok but we should probably have a
release note.
> Implement error handling/parameter checking in Clob.setString
> -------------------------------------------------------------
>
> Key: DERBY-2769
> URL: https://issues.apache.org/jira/browse/DERBY-2769
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.3.1.4
> Reporter: Kristian Waagan
> Assignee: Yun Lee
> Attachments: DERBY-2769-1.patch, DERBY-2769-1.stat,
> DERBY-2769-2.patch, DERBY-2769-2.stat, DERBY-2769-3-a.diff,
> DERBY-2769-3-a.stat, DERBY-2769-3-b.diff, DERBY-2769-3-b.stat
>
>
> The error handling, or parameter checking, in Clob.subString is not adequate.
> There are four parameters that can be invalid;
> * pos
> * str
> * offset
> * len
> The first one is already handled properly, the remaining three are not. They
> typically result in some low-level exception like a NPE.
> I have not found anything in the JDBC specification nor JavaDoc that dictates
> the behavior, except for that SQLException should use states defined in the
> SQL 2003 specification. A brief search there resulted in the following
> possibilities:
> 22003 - numeric value out of range
> 22004 - null value not allowed
> 2200F - zero-length character string
> 22011 - substring error
> 22023 - invalid parameter value
> Some of these are already defined by Derby, but with unsuitable or very
> specific error messages.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
