Bryan Pendleton wrote:
Fernanda Pizzorno wrote:
What we are looking for is a mechanism that we can use to implement the
ResultSet#rowUpdated() method.
I think I understand better now. Let me try stating it in my own words,
and you can tell me if I am on the right track or not.
- We want to implement ResultSet.rowUpdated() in the Derby Net Client
- On the server side, we have a data structure which holds a bunch of
auxiliary information for each scrollable updatable cursor. In
particular,
this data structure has a boolean field for each row which records
whether or not the row was updated.
- So once we get to the server side, we have the information that we need
to be able to answer the question.
- That means that now all we have to do is to figure out what message the
client should send the server when the client calls rowUpdated(), and
what message the server should return.
- Lastly, you have been looking at the "Update Hole" mechanism in DRDA,
because it seems to specify a way to convey extra information about
a row in the result set.
- However, the precise specification for the "Update Hole" field in DRDA
has to do with the scenario in which the update to a row causes it
to *move* within the result set, so that it's no longer at the same
*position* in the result set, which is a different semantic than what
is needed for the rowUpdated() method.
- But it seems like the mechanism is roughly similar to what is needed,
so you're proposing to extend it slightly to have an alternate sort
of "Update Hole" which has the semantic: "row is still in the same
position in the result set, but it has been updated in ways which did
not change its position".
- Then, when the client received that special variant Update Hole, it
would return "true" for the rowUpdated() method.
Did I understand correctly?
thanks,
bryan
Yes, that's what I meant.
Fernanda
