db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernt M. Johnsen" <Bernt.John...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-7) Bug in NULLIF Function
Date Thu, 04 May 2006 19:53:29 GMT
>>>>>>>>>>>> Myrna van Lunteren (JIRA) wrote (2006-05-04
17:47:27):
>     [ http://issues.apache.org/jira/browse/DERBY-7?page=comments#action_12377852 ] 
> 
> Myrna van Lunteren commented on DERBY-7:
> ----------------------------------------
> 
> Hi Berndt,
> 
> I happened to spot the following in your check-in for revision 399657 for the test jdbcapi/resultset.java:
> 
> +                               } catch(SQLException ex){
> +                                       if (ex.getSQLState().equals("22005")) {
> +                                               if (s.getBytes (i) != null)
> +                row.append(new String(s.getBytes(i)));
> +                                               else
> +                row.append(s.getBytes(i));
> +                                       } else throw ex; 
> +                               }
> 
> I think what has happened here is that you applied original patch of
> DERBY-7 to 10.1.

No, I did a
svn merge -r227280:227281 ../trunk

> However, the test resultset.java has since had some work done on it,
> and I'm specifically concerned that you may have missed the changes
> I worked on for DERBY-903, which were committed with revision 378337
> and 379643.

I think the explanation is that DERBY-7 was committed long before
DERBY-903, but now they were applied to 10.1 in the opposite order.

> This eliminates the use of the constructor 'new String(bytes[]),
> which is non-portable...It constructs a string by decoding the bytes
> using the default platform charset. This can lead to encoding
> related problems.  For this case, you should probably use the
> constructor that takes in the encoding. ie new String(byte[], String
> charsetname).
> 
> Can you please rework this section of resultset.java to not use an
> encoding-safe mechanism?  Just compare with the current 10.2
> resultset.java...


Thanks for spotting this one, I'll look into it.

-- 
Bernt Marius Johnsen, Database Technology Group, 
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway

Mime
View raw message