Re: Prepared Statements

Kim Ho wrote:

>>>In any case, here is a revised version of the patch. =) Thanks for the
>>>pointers.
>>>
>>>
>>>
>>I must be missing something, but I don't see any difference with the
>>previous version ....
>>
>>
>>
>There is an attempt to do a:
>Double.valueOf(x.toString());
>
>in bindNumbers to ensure that the object's string representation is a
>number. This is what you were talking about before right?
>
>
Oh, I see...
Now you end up parsing it twice in some cases (once in removeRadix(),
and once again in bindNumber()) - why don't you merge those two together
to save one parse?

Not that I care, because I am not going to be able to use this at all
(and will have to build my own driver if it ever gets in), because it
breaks the existing functionality :-(

The hex thing may be questionable - although, I do sympathize with
people who may be using it currently, and will be forced to rewrite
their app now, but, at least, they have a (relatively) simple solution
(which is to take on the  backend's parsing of hex numbers, and do it on
the app side)...
What I am concerned about is the "in" thing -

select * from sometable where x in ?;
setObject (1, "(1,2,3,4,5)");

that works just fine right now, and will be irreperably broken by this
patch...
No way I am going to rewrite all the existing code to do something like

select * from sometable where x in

(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)
... and then loop through the set and set each param separately, hoping
I have enough questionmarks to fit them all in :-)


Dima

>About breaking functionality with hex.
>
>I'm not sure about this, maybe we could get other opinions in
>(specifically Dave and Barry). I'm not so sure that it should be
>allowed. (I am not saying that it is not useful.)
>
>Cheers,
>
>Kim
>
>