Anders,
This is a great idea. This would certainly solve the memory problem for
inserts. Selects on the other hand wouldn't be helped since you need to
read the entire value first before you can get to the rest of the values.
thanks,
--Barry
Anders Bengtsson wrote:
> On 2002-04-18 Joe Shevland wrote:
>
>
>>I figured that the differences in the types and how the backend
>>handles them precludes actually trying to do anything to optimise the
>>behaviour in the client interface. For example, can I use the socket
>>connection when performing an update operation to stream binary data to
>>the backend, or does it expect the whole statement to be character data
>>sent at the one time?
>
>
> Hi Joe!
>
> It's only possible to send the whole statement, data and query, as
> character strings.
> Today when you add a stream parameter to a PreparedStatement it
> immediately reads the stream into a String. Then it concatenates the
> query and the parameters into an even larger String, which is scanned
> for escape codes and such (creating yet another huge String!). Finally
> it's all written to the backend.
>
> A better way would be to keep the stream parameter stored as a
> InputStream until the query is executed, and then stream it directly to
> the backend. This requires some changes in how the PreparedStatement
> class deals with parameters and how the PreparedStatement is fed to the
> backend. The escape scanning will have to be rewritten as a filtering
> stream, etc.
>
> It would imply a change in semantics of a PreparedStatement, that it
> could only be executed one time once the parameters are set. But I
> wouldn't be surprised if that is what the JDBC spec. says anyway.
>
> (Today's internal interface in Connection assumes a String to be
> executed. Perhaps a new interface "Query" with a "StringQuery" class to
> encapsulate simple string queries and something for prepared queries
> could be used. But that's only my thoughs on how to implement it).
>
> /Anders
>
