Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Fri, 18 May 2012 21:47:19 +0000 (UTC)
From: "Dag H. Wanvik (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <359007844.16541.1337377639671.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (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.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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