db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fernanda Pizzorno <Fernanda.Pizzo...@Sun.COM>
Subject Subject: Detectability of updates in DRDA
Date Fri, 03 Mar 2006 15:38:53 GMT
I am going to start working on detectability for scrollable insensitive 
update result sets on the client driver and I was wondering if someone 
could answer to the following question posted by Dag:


DERBY-775: Network client: Add support for scrollable, updatable, 
insensitive result sets

[...]

b) Detectability

In the spec, we required that we be able to detect deletes and updates
to the rows in the result set:

     deletesAreDetected(TYPE_SCROLL_INSENSITIVE) -> true
     updatesAreDetected(TYPE_SCROLL_INSENSITIVE) -> true

(Since inserts are not visible, they can not be detectable, either).
DRDA supports detection of holes in the following manner (quote,
P. 656):

   "To present a static size and static ordering for the result table, the
   relational database may return a hole to the application that fetches
   an updated or deleted row in the result table. A hole in the result
   table occurs when there is a difference between the result table and
   the underlying base table. No data can be fetched from a hole, and the
   hole is manifested in the QRYDTA as a row consisting of a non-null
   SQLCARD and a null data group.

   When the current value of a row no longer satisfies the
   select-statement or statement-name, that row is visible in the cursor
   as an update hole , where the SQLCARD has a warning SQLSTATE of 02502.

   When a row of the result table is deleted from the underlying base
   table, the row is visible in the cursor as a delete hole , where the
   SQLCARD has a warning SQLSTATE of 02502."

For deletes, the "delete hole" is exactly what we need to support
ResultSet#rowDeleted().

For updates, is is not exactly what we want, since we do not intend to
requalify a row after it has been updated (thereby possibly making it
an "update hole"). On the other hand, when we update a row and let it
remain in the result table, DRDA offers no means of conveying that the
row has been changed in the sense of JDBC ResultSet#rowUpdated(), as
far as I can tell.

*Question 2*: Is there some way we can detect the latter without
violating the protocol? One could imagine signalling this using
another warning SQLSTATE. Would this be an acceptable tweaking of the
DRDA?

[...]

Thanks in advance.

Fernanda

Mime
View raw message