db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-775) Network client: Add support for scrollable, updatable, insensitive result sets
Date Wed, 19 Apr 2006 14:52:35 GMT
     [ http://issues.apache.org/jira/browse/DERBY-775?page=all ]

Dag H. Wanvik updated DERBY-775:

    Attachment: derby-775-6.stat

A new version of the patch. Changes details

  - Merge conflict with David's changes for am/ResultSet.java have
    been resolved, in some cases by keeping his changes and dropping
    similar changes in the previous version of this patch, in other
    cases vice versa. Notably this patch in a few places replaces
    XJ086 with XJ083. This makes for more precise indication on
    offending operation and more similarity to embedded). David, it
    would be nice if you could have a look at this to see if it is ok
    with you.

  - Fixed a wrong operation string (cancelRowUpdates) to

  - An added sane assertion for the case Øystein asked for in

  - A fix to make sure detectability for rowDeleted isn't introduced
    for FORWARD_ONLY result sets (side-effect of offering it for SUR).

  - Removed a test comment line no longer pertinent in

I have run derbyall for Solaris 10/x86 with Sun JDK 1.5 again.

Answers and comments to Øystein's latest comments.

>>>>> "Øystein" == Øystein Grøvlen (JIRA) <derby-dev@db.apache.org>

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

You are right, I added a sane mode invariant check.

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

I was just trying to guess at why the restriction was introduced or
why it was felt acceptable. My thought was it might be easier to
specify the cursor's whereabouts in the forward only case ("just
before next row").

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

I guess you could argue that keeping the forward-only behavior and
then possibly changing both FO and SUR at a later date is a better
(more conservative) approach. But lifting the requirement should
hopefully not prove too problematic for the end user.  Anyway, this
patch is about making the client version of SUR; embedded behaves the
same way, so I suggest we don't change this for now. If you think SUR
should be changed to follow the semantics of forward-only, please file
a JIRA for it. Alternately we should file a JIRA to the lift the
requirement for FO unless there is a good reason to keep it the way it

> 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, derby-775-6.diff, derby-775-6.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