[ 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: 10.2.0.0 > 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: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
