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
>
>
This archive was generated by hypermail 2.0.0 : Mon Jan 11 2010 - 15:27:01 EST