Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cayenne.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-Id: <BFECDE99-DD56-41C9-A371-E327E6688EB9@objectstyle.org>
From: Andrus Adamchik <andrus@objectstyle.org>
To: dev@cayenne.apache.org
In-Reply-To: <9E32472B-1498-443C-A637-A11C98E8A3AE@objectstyle.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: [jira] Updated: (CAY-1298) String no longer works in query when
  column type is Integer
Date: Mon, 11 Jan 2010 22:26:11 +0200
References: <1058971447.157771263235134613.JavaMail.jira@brutus.apache.org>
  <244F5CD8-D896-4463-BB57-567C674B986D@objectstyle.org>
 <3219fff71001111139v5a1cb4dag20296e0d4714bd8f@mail.gmail.com>
 <9E32472B-1498-443C-A637-A11C98E8A3AE@objectstyle.org>

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);
+        }
      }


Andrus

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
>
>