-----BEGIN PGP SIGNED MESSAGE----- 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. Dan. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBvgwNIv0S4qsbfuQRAnyDAJ9pZeFaHTNhoPJdwh3u23a0bjHiBwCfTWsA bKLAD07zGpI8KT5R2pGgAXc= =V1a9 -----END PGP SIGNATURE-----
