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
