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 Sun, 09 Apr 2006 03:19:25 GMT
     [ http://issues.apache.org/jira/browse/DERBY-775?page=all ]

Dag H. Wanvik updated DERBY-775:

    Attachment: derby-775-4.stat

Answers to Øystein's latest comments and questions. I synced up to svn
392313 and ran derbyall again (Solaris 10/x86, Sun JDK 1.4.2).

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

Øystein> What about the constants like 1004.  How did you figure out
Øystein> which values to use?

These constants are from the Java ResultSet interface:

    int TYPE_FORWARD_ONLY = 1003;

Øystein> It might be conservative, but it is not very cautious.  It
Øystein> seems like you silently ignore scenarios where you get both a
Øystein> warning and data, and the case where you get no data and no
Øystein> warning.  Should not these scenarios generate an error or at
Ø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

Øystein> '_'-suffix for method names. Is that common?

There is already a API method called getWarnings, so I added a suffix
to indicate that this is an internal method. But you are right, this
suffix is not in frequent use, so I have changed the name to

Øystein> Is there a particular reason why this code cannot be common
Øystein> to all result sets?

I guess not, but I think the call to getAbsoluteRowset is necessary
and sufficient.

Ø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.

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

Øystein> Good.  I see there are few other places that could have used
Øystein> this method (insertRow(), refreshRow(),
Øystein> checkUpdatePreconditions().  Either you could change that, or
Øystein> we should send a note to David to make him aware of it for
Øystein> his internationalization work.

I agree. Although it might make as much sense do do this as part of a
general clean-up, I changed those to use the same method
(checkForUpdatableResultSet), as well, since it moves in the right
direction and is SUR-related.

> 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: JDBC, Network Client
>     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
> 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