db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen (JIRA) <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-775) Network client: Add support for scrollable, updatable, insensitive result sets
Date Tue, 18 Apr 2006 13:02:18 GMT
    [ http://issues.apache.org/jira/browse/DERBY-775?page=comments#action_12374929 ] 

Øystein Grøvlen commented on DERBY-775:

Changes looks good.  I have follow-up comments on a two issues:

Dag H. Wanvik (JIRA) wrote:
> Øystein> least be handled by an assert?
> I think changing existing code semantics is less cautious than keeping
> it ;) But I agree it could be useful to include an assert of the new
> case ensuring that there is nulldata whenever we get the new warning
> (SUR scenario).  Did that. For the "old" case, I am *not* certain it
> could never happen in some scenario, so I won't add an assert for
> that.

That you are not certain that it could never happen, worries me even
more since you have disabled the handling of this case.  Earlier, this
case would result in a "delete hole".  Now, it is just ignored.  What
will happen if a client tries to access the current record?

> Øystein> To me it seems like a common behavior for forward-only and
> Øystein> scrollable cursors should be more important than a specific
> Øystein> behavior for any of them.
> I guess in a forward-only updatable result set, the expectation would
> be that after updating a row you would want to reposition to the next
> row always.
> In a scrollable result set we have no a priori direction in which to
> move after an update, so IMHO it does not seem logical to inherit the
> behavior of forward-only for scrollable.

I cannot see how direction is relevant.  This is about being able to
access the current record after it has been updated before any
navigation.  I do not understand why that should make more or less
sense for SUR than for forward-only result sets.

> If anything, I would suggest removing this behavior for
> forward-only. Anyway, the embedded SUR does not require repositioning
> either, so if you want this changed, you should log a JIRA issue, I
> think.

I think you are saying that for SUR it makes most sense to still be
able to access the current record after it has been updated.  I agree,
and I also agree that would be the ideal solution for forward-only.
However, given that forward-only has a different behavior, my question
is why you think it is more important to implement the proposed
behavior for SUR than to have a common behavior for both?

> Network client: Add support for scrollable, updatable, insensitive result sets
> ------------------------------------------------------------------------------
>          Key: DERBY-775
>          URL: http://issues.apache.org/jira/browse/DERBY-775
>      Project: Derby
>         Type: New Feature

>   Components: Network Client, JDBC
>     Versions:
>     Reporter: Dag H. Wanvik
>     Assignee: Dag H. Wanvik
>     Priority: Minor
>  Attachments: 775-writeup.txt, derby-775-1.diff, derby-775-1.stat, derby-775-2.diff,
derby-775-2.stat, derby-775-3.diff, derby-775-3.stat, derby-775-4.diff, derby-775-4.stat,
derby-775-5.diff, derby-775-5.stat
> This is a part of the DERBY-690 effort.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message