cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: [jira] Updated: (CAY-1298) String no longer works in query when column type is Integer
Date Mon, 11 Jan 2010 20:26:11 GMT
On the other hand 813661 is a pretty recent commit done on September  
11, 2009. So probably changing it won't cause new regression bugs. My  
only issue with the patch is this:

-public class CharType implements ExtendedType {
+public class CharType extends AbstractType {

But this part of it can probably be restored:

@@ -157,7 +164,14 @@
              int type,
              int precision) throws Exception {

-        st.setString(pos, (String) val);
+        // if this is a CLOB column, set the value as "String"
+        // instead. This should work with most drivers
+        if (type == Types.CLOB) {
+            st.setString(pos, (String) val);
+        }
+        else {
+            super.setJdbcObject(st, val, pos, type, precision);
+        }


On Jan 11, 2010, at 9:53 PM, Andrus Adamchik wrote:

> On Jan 11, 2010, at 9:39 PM, Andrey Razumovsky wrote:
>> Actually I've been using such syntax myself (we also talked about  
>> that when
>> discussing generified expressions).
> yes, but I wish we define an explicit set of allowed conversions  
> that work the same across DB's (by virtue of Cayenne doing those  
> conversions). E.g. we'd require format string for Date conversions,  
> etc.
>> I really want this ability to stay in
>> some way, since it saves time and unnecessary code. Currently it  
>> works for
>> me in MySQL when id column is BIGINT (and I'm searching by a  
>> string). Most
>> DBMS allow comparing string to an int, why shouldn't we?
> My problem with this is consistency. The patch will work or fail  
> depending on a specific driver (or a driver version - something I  
> observed on postgresql in the past), and a specific type of String  
> to X conversion. Actually the current 'setString' approach is prone  
> to the same problem, but changing it now opens possibility of new  
> regression issues. So we'll be likely fixing a subset of cases and  
> breaking some other subset, and that won't be clear immediately.
> Andrus

View raw message