On 23-Jun-06, at 4:32 PM, Mark Lewis wrote:
>> Hmmm maybe I should read before sending. It appears that both input,
>> and output can be text. The only catch with output is that you have
>> to do a describe first to get the types. This may negate any gains on
>> small result sets, but certainly for large ones it would help.
>
> Disclaimer: this is my first real trip through the v3 protocol and the
> JDBC driver source in general. So take anything below with several
> grains of salt.
>
> As far as I can tell from reading the JDBC CVS code, the sequence for
> preparing and executing a statement for the first time is:
>
> PREPARE (name=my_statement)
> DESCRIBE STATEMENT (name=my_statement)
> SYNC/FLUSH
> Read Responses
>
> BIND (portal=my_portal)
> DESCRIBE PORTAL (name=my_portal)
> EXECUTE (portal=my_portal)
> SYNC/FLUSH
> Read Responses
>
> So it seems that we could do all text, mixed or all binary parameters
> without adding a round trip, because we already do an extra round trip
> when a statement is first prepared and we already know all of the
> parameter types.
Yup, you could, however the real win here is on parsing the return
parameters, going from object to string is not terribly expensive.
Network times are probably a red herring.
>
> We could do all text or all binary outputs without adding a round trip
> as well, because you can globally set the output format, but to do
> mixed
> outputs we'd need to execute the DESCRIBE PORTAL to get the return
> types, and then (not sure?) execute BIND again with different format
> parameters?
Yes, you can do binary results, but consider what happens if someone
returns a type the driver doesn't know about ?
>
> -- Mark Lewis
>
