Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Fri, 03 Mar 2006 16:38:53 +0100
From: Fernanda Pizzorno <Fernanda.Pizzorno@Sun.COM>
Subject: Subject: Detectability of updates in DRDA
To: Derby Development <derby-dev@db.apache.org>
Message-id: <4408630D.5070900@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930)

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