Oliver,
So if we defer parsing, this will require changing the strategy to
create the parameters as they are set, or registered.
I would suggest using an ArrayList of Parameters, and grow this as
required, then parse when it is executed.
Do you have any suggestions ?
Dave
On 14-Jun-05, at 7:21 PM, Oliver Jowett wrote:
> Dave Cramer wrote:
>
>> Well the good news is that the driver and the backend will pass
>> the cts
>> with this patch.
>>
>> Rather than commit this as is, I'd like to discuss the patch as it
>> is.
>>
>> I'm really not happy with the handling of IN/OUT parameters in the
>> query executor, however deferring parsing doesn't seem to be an
>> option
>> either.
>>
>
> I don't think your approach works, though; consider this (untested)
> example:
>
> CallableStatement cs = conn.prepareCall("{call f(?*4,?)}");
> cs.setInt(1,42);
> cs.registerOutParameter(2,Types.INTEGER);
>
> The query gets parsed into these fragments:
>
> 0:"select * from f("
> 1:"*4,"
> 2:") as result"
>
> As I read your code, that's going to discard fragment 1 blindly in the
> query executor, resulting in this query:
>
> "select * from f($1) as result"
>
> which is wrong.
>
> The logic that decides to remove OUT placeholders needs to be aware of
> the rest of the {call} structure (mainly, comma separation of
> parameters) to do it correctly, and I really don't think that the
> QueryExecutor implementations are the right place for that..
>
> -O
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>
>