Andreas Korneliussen wrote: > Hi, > > The implementation of SUR just builds on the existing scrollable > resultsets, which collects all rows into a table. We have extended this > table to also contain RowLocation and some metadata. > This means we do not need to change the store module to navigate > backward etc - no changes in the store module. > > Updatable cursors in derby uses RowLocation, however the row is > guaranteed to be locked (current row has update lock, I think, > regardless of isolation level). > As for holdable cursors, forward only updatable cursors require the user > to navigate to the next row after a commit, thereby getting a new > rowlocation, on a row which is locked. > > I will propose a more detailed solution tomorrow, so it becomes more > clear, and less mysterious, what I really propose :-) > Any other suggestions are of course welcome.
Was this posted, the more detailed solution? There was a little more detail on a proposed interaction with online compress, but I think that is based upon a whole lot of design thinking and assumptions which has not made it to list. I'd assumed you meant you were going to describe your proposed full solution to SUR, I'm interested to know your approach works with the various isolation levels, how you handle deleting the rows, how holdability is supported, etc. And if during working on this you had to work out how scrollable read-only cursors are implemented, adding that as background would be excellent. Great knowledge to add to the community. Don't assume reviewers know how things work today, provide as much information as you know. Thanks, Dan.
