db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-129) 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.
Date Fri, 18 May 2012 12:42:07 GMT

     [ https://issues.apache.org/jira/browse/DERBY-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Knut Anders Hatlen updated DERBY-129:

    Attachment: d129-1a.diff

Attaching patch d129-1a.diff, which is based on warn.diff attached to
DERBY-5537 with additional code to make the network server propagate
the warning to the client, and changes to make the tests pass.

Detailed description of the changes:

- iapi/types/SQLBinary.java
- iapi/types/SQLChar.java

Added code to generate the DataTruncation warning.

One thing to note is that the javadoc for java.sql.DataTruncation says
the data size and the transfer size are to be specified in number of
bytes, so SQLChar needed some logic to convert character length to
byte length. I refactored the writeUTF() method in that class in order
to avoid duplication of the bit-fiddling logic when calculating the

Another thing to note is that we don't know the index of the column
that's being truncated, so the index field of the DataTruncation
warning is set to -1, as DataTruncation's javadoc says getIndex() may
return -1 if the column index is unknown.

- iapi/types/SQLBit.java
- iapi/types/SQLBlob.java
- iapi/types/SQLVarbit.java

Use the shared truncate() method added to SQLBinary to truncate and,
if required, add a warning.


Changes to allow adding the warning even if we don't end up returning
a JDBC ResultSet, in which case the warning will be added to the
executing statement.

- impl/drda/DRDAConnThread.java

DataTruncation.getErrorCode() always returns 0 (there's no way to
change that), but the protocol uses code 0 to indicate that the client
should discard the warning. The patch makes the server send error code
10000 (ExceptionSeverity.WARNING_SEVERITY) for DataTruncation, like it
does for all other warnings.

- iapi/services/io/CounterOutputStream.java

Modified to allow it to be used to count number of bytes in a string
when generating DataTruncation warning in SQLChar. Its javadoc says
the stream will discard bytes written to it if it's created with the
zero-arg constructor. However, it does not discard the bytes and fails
with a NPE when trying to write to a null stream when used this way.
The patch modifies the write methods to do what the javadoc says they
should (and removes one of them - write(byte[]), since the default
method inherited from OutputStream does the right thing, that is, it
forwards the calls to write(byte[],int,int)).

- shared/common/reference/SQLState.java

Renamed constant from LANG_FILE_ERROR to LANG_IO_EXCEPTION since the
corresponding error message doesn't necessarily have to do with files.
Since the message wasn't actually in use before the patch, even though
it existed in the code, no callers had to be changed because of this.
The patch makes use of the message in SQLChar.getUTF8Length().

- functionTests/tests/lang/CastingTest.java

Added a test case that verified that DataTruncation warnings were
added correctly to ResultSets and Statements. Enabled the test for
client/server mode as well to verify that the warnings made it over to
the client.

Additionally, lots of canons had to be updated because of new
warnings. Most of these were the expected truncation warnings, but
there were also some new warnings of the type

WARNING 01003: Null values were eliminated from the argument of a column function.

that appeared because of the changes that propagated warnings from
sub-queries of DML statements up to the executing statement. The new
warnings looked correct to me.

The canons were either changed to expect the new warnings, or, in the
cases where the new warnings added too much noise (in particular the
old framework tests that include LockTableQuery.subsql), the queries
were changed so that they would not emit DataTruncation warnings.
> 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:
>            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


View raw message