Kris Jurka wrote:
>
> On Sat, 22 May 2004, Oliver Jowett wrote:
>>My V3 patches handle these cases by closing the connection entirely &
>>throwing an exception (i.e. providing a short stream or throwing
>>IOException is a fatal error). This seemed better than silently padding
>>with bogus data.
>>
>>I don't see that either case is a "normal" case we should be supporting
>>-- we just need to be sure we clean up properly.
>>
>
>
> I don't consider abandoning the connection "cleaning up properly."
I don't see what isn't cleaned up by closing the connection. It seems
the simplest and safest way of handling this sort of error.
> With
> the V3 protocol we have a reasonable recovery method because we will
> detect this error at Bind time and simply not issue the Execute. In the
> current code's case it seems the only way to do it is to deliberately
> introduce a syntax error to make the query fail.
We'd have to insert an artificial syntax error (another Parse after the
Bind that failed) anyway to force transaction rollback.
I'm reluctant to allow the txn to continue as a) it's inconsistent with
how other errors are handled and b) the distinction between Bind and
Execute is a bit fuzzy. There is some portal setup work run on Bind, and
I'm not sure if we can assume that a Bind immediately followed by a
ClosePortal does not modify the DB in any way.
Really, this is an *application error*, so I'm happy with anything that
preserves data integrity in the DB, even if it toasts the application's
current connection. If the application doesn't want this behaviour, it
shouldn't give the driver bad streams!
> Another issue that just came to me is what is the desired behavior for
>
> ByteArrayInputStream bais = new ByteArrayInputStream(new byte[1000]));
> PreparedStatement ps = conn.prepareStatement("INSERT INTO t VALUES (?)");
> ps.setBinaryStream(1, bais, 100);
> ps.execute();
> ps.execute();
> ps.execute();
>
> Should each inserted row have the same values? Should the second row get
> the second 100 bytes and the third row get the third 100?
I'm sure that there is something somewhere in the spec that says that
the client has to keep the stream in an appropriate state until
execution (but now I can't find it anywhere!). So I'd expect in this
case to get bytes 0-99, 100-199, 200-299 inserted into the three rows
respectively.
More fun is what happens if you do the above with addBatch() /
executeBatch(); should that be equivalent to treating addBatch() as a
"query execution"? What if we want to delay reading the data until the
real batch execution?
-O
