You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Myrna van Lunteren (JIRA)" <de...@db.apache.org> on 2006/05/04 19:47:27 UTC
[jira] Commented: (DERBY-7) Bug in NULLIF Function
[ 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.
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.
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...
Thx,
Myrna
> Bug in NULLIF Function
> ----------------------
>
> Key: DERBY-7
> URL: http://issues.apache.org/jira/browse/DERBY-7
> Project: Derby
> Type: Bug
> Components: SQL
> Versions: 10.0.2.0
> Reporter: Tulika Agrawal
> Assignee: Mamta A. Satoor
> Priority: Minor
> Fix For: 10.2.0.0, 10.1.3.0
> Attachments: Derby-7.txt, Derby7NullIf061005svndiff.txt, derby-nullif.patch, derby7Nullif080205svndiff.txt
>
> Reporting for Christian d'Heureuse, filed on derby-dev list.
> The NULLIF built-in function of Cloudscape 10.0.1.0 beta seems to accept
> only string values.
> Examples:
> values nullif('a','b');
> --> OK
> values nullif(1,2);
> --> Error message: "ERROR 42X89: Types 'CHAR' and
> 'INTEGER' are not type compatible. (Neither type
> is assignable to the other type.)"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-7) Bug in NULLIF Function
Posted by Myrna van Lunteren <m....@gmail.com>.
On 5/4/06, Bernt M. Johnsen <Be...@sun.com> wrote:
> The net result from the two mentioned commits is as far a I can see
> the diff below. Myrna: can you confirm?
>
> Index:
> java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/resultset.java
> ===================================================================
> ---
> java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/resultset.java
> (revision 399685)
> +++
> java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/resultset.java
> (working copy)
> @@ -798,12 +798,9 @@
> try{
> row.append(s.getString(i));
> } 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;
> + if (ex.getSQLState
> ().equals("22005"))
> + row.append("Invalid
> Conversion Error\n");
> + else throw ex;
> }
> }
> row.append("}\n");
Hi Berndt,
I think that's it.
Myrna
Re: [jira] Commented: (DERBY-7) Bug in NULLIF Function
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
> 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.
>
> 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).
The net result from the two mentioned commits is as far a I can see
the diff below. Myrna: can you confirm?
Index: java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/resultset.java
===================================================================
--- java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/resultset.java (revision 399685)
+++ java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/resultset.java (working copy)
@@ -798,12 +798,9 @@
try{
row.append(s.getString(i));
} 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;
+ if (ex.getSQLState().equals("22005"))
+ row.append("Invalid Conversion Error\n");
+ else throw ex;
}
}
row.append("}\n");
--
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway
Re: [jira] Commented: (DERBY-7) Bug in NULLIF Function
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
>>>>>>>>>>>> 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