db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4184) Calling deleteRow() on a ResultSet that has been commited throws no error
Date Mon, 27 Apr 2009 23:39:30 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Mike Matrigali updated DERBY-4184:

I believe the current behavior is correct with respect to "held" cursors.  Maybe someone can
quote the exact standard.  Basically at commit time a held cursor is not positioned on the
current row, it is said to be positioned before the next row.  Thus there is a very limited
number of valid operations on a cursor 
following a commit - i think it is just next and close.  This may not be intuitive but I believe
it implements the standard and the behavior is well defined, and allows an easier non-lock
holding implementation than guaranteeing the "current" row is available.  

My experience is with the original cursor implementation, not with scrollable cursors.

> Calling deleteRow() on a ResultSet that has been commited throws no error
> -------------------------------------------------------------------------
>                 Key: DERBY-4184
>                 URL: https://issues.apache.org/jira/browse/DERBY-4184
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Server
>    Affects Versions:
>         Environment: Not relevant.
>            Reporter: Tiago R. Espinha
>            Priority: Minor
>         Attachments: ReproHoldCursorBug.java
> This issue was originally found on DERBY-3839.
> The steps to get this error happening are as follows:
> 1) Set auto commit to false
> 2) Create a Statement with the following parameters:
> 3) Create a ResultSet by having a SELECT on an executeQuery() on a table with at least
one row.
> 4) Do a next(); on the ResultSet. Then commit() and try to deleteRow() on the ResultSet.
> According to holdCursorJDBC30.out, the deleteRow() should throw an 'Invalid cursor state
- no current row' but it doesn't, not when using Java code.
> The problem here is the ResultSet.CONCUR_UPDATABLE. By setting this property, the ResultSet
checks that the property is different from CONCUR_READ_ONLY and doesn't do a proper check
on checkForUpdatableResultSet(). Without this check, the deleteRow() executes successfully
BUT, the row does NOT get deleted.
> After talking about this with Kathey, we agreed that the exception should always happen.
If an exception isn't thrown and the row isn't deleted, then this is certainly misleading

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message