db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: [VOTE][PATCH]delete from the resultset using JDBC 2.0 UpdatableResultsetAPIs
Date Mon, 13 Dec 2004 21:39:25 GMT
Hash: SHA1

Mamta Satoor wrote:

> I thought further about the 3 issues that we have been discussing.
> 2a)We can continue to make the columns that are not nullable as null but
> since it is just a hole, a program should not be using the contents of the
> deleted hole anyways. And the program can find out from rowDeleted
> if they are on a deleted hole.
> 2b)Just as with positioned deletes, the ResultSet can be positioned right
> before the next row (as Dan suggested in his alternative approach).

For the forward result set, moving off the row after a delete row is the
same as not detecting deletes, as the ResultSet can never be positioned
on the deleted row.

I think this is the correct approach.

I think allowing any of the getXXX() methods to return NULL when the
column's metadata says it is not nullable is trouble. We have seen
issues in the past when Cloudscape had a system table column incorrectly
labelled as not-nullable and it contained nulls, which were then
returned from a ResultSet.

In the future I think when/if Derby does support 'holes' in scrollable
updateable result sets, then an application can use rowDeleted() to see
if the row is a 'hole' (has been deleted), but any getXXX() call on such
a row should throw an exception.


Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


View raw message