[
https://issues.apache.org/jira/browse/DERBY-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13279223#comment-13279223
]
Dag H. Wanvik commented on DERBY-129:
-------------------------------------
Hi Knut, thanks for this cleanup! I hope this can go in along with DERBY-5749
into 10.9 (both concern truncation diagnostics).
Some small nits:
SQLBinary#truncate
- If value is lob, the call to first getLength, then to getValue, can
cause us the risk of havin to read a lob twice. If we call getValue
first, we can save the call to getLength, no?
Or, in all of SQLBit, SQLVarBit and SQLBlob, the actual width is
actually available at the call site, so it could be passed in
instead of doing another getLength? But maybe the lob is already in
memory, so LOB reading cannot take place here.. if so, a comment
that the getLength should be cheap would be nice.
SQLChar#getUTF8Length
- I think we could use the less specialized class ObjectOutputStream
instead of FormatIdOutputStream here for "cs". The write method
isn't overriden by FormatIdOutputStream, though, but it made me wary
at first, lest extra bytes were written. writeUTF needs
ObjectOutputStream, not FormatIdOutputStream.
CastingTest:
- /**
* Check the results for the queries in testDataTruncation().
*/
private void checkDataTruncationResult(Statement s, String sql)
Might be good to document the expected row behavior: 1, 0 and 2
warnings for rows 1,2 and three respectively, and 3, 3 and 4 in
actual dataSize in the Javadoc.
- checkDataTruncationResult(s,
"values (cast('abc' as clob(2)), cast('de' as varchar(2)))," +
" (cast('fg' as clob(2)), cast('hi' as varchar(2)))," +
" (cast('jkl' as clob(2)), cast('mnop' as varchar(2)))");
Why not clob(2) in column 2 on these rows? Copy/paste error?
- DRDAConnThread
Is the code path
private int getSqlCode(int severity)
{
if (severity == CodePoint.SVRCOD_WARNING) // warning
return 100; //CLI likes it
still relevant now that you test "instanceof SQLEWarning"?
> Derby should throw a truncation error or warning when CASTing a
> parameter/constant to char or char for bit datatypes and the data is too
> large for the datatype.
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-129
> URL: https://issues.apache.org/jira/browse/DERBY-129
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.0.2.1
> Reporter: Mamta A. Satoor
> Assignee: Knut Anders Hatlen
> Labels: derby_triage10_8
> Attachments: d129-1a.diff
>
>
> Derby doesn't throw a truncation exception/warning when data is too large
> during casting of constants or parameters to character string or bit string
> data types.
> Following is ij example for constants which is too big for the datatype it is
> getting cast to
> ij> values (cast ('hello' as char(3)));
> 1
> ----
> hel
> 1 row selected
> ij> values (cast (X'0102' as char(1) for bit data));
> 1
> ----
> 01
> 1 row selected
> Following code snippet is when using parameters through a JDBC program
> s.executeUpdate("create table ct (c CLOB(100K))");
> //the following Formatters just loads cData with 32700 'c' characters
> String cData =
> org.apache.derbyTesting.functionTests.util.Formatters.repeatChar("c",32700);
> //notice that ? in the preared statement below is bound to length 32672
> pSt = con.prepareStatement("insert into ct values (cast (? as
> varchar(32672)))");
> pSt.setString(1, cData);
> //Derby doesn't throw an exception at ps.execute time for 32700 characters
> into 32672 parameter. It silently
> truncates it to 32672
> pSt.execute();
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
