db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Korneliussen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1361) positioned updates and deletes allowed after a commit without repositioning the cursor - if the table is indexed on the columns selected
Date Thu, 08 Jun 2006 15:34:30 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1361?page=comments#action_12415365 ] 

Andreas Korneliussen commented on DERBY-1361:
---------------------------------------------

It seems to me that it is the store layer which has the knowledge on if a cursor has lost
its position as a consequence of a commit. After a commit, the scanstate will be SCAN_HOLD_INPROGRESS.

The optimization in DERBY-1087 causes IndexRowToBaseRowResultSet (in SQL execution layer)
to no longer need to ask its source resultset for the current row (and thereby doing extra
qualification ). Since it does not ask its source resultset, the source resultset no longer
access the store layer and gets the exception that the cursor is not on a row.

I would propose to fix this by letting IndexRowToBaseRowResultSet call a new method (isCurrentPositionValid())
on its source resultset. The source resultset (i.e TableScanResultSet) may implement this
by calling a new method in store's ScanController to check that the position is valid.

In terms of internal interface changes, this means that if I follow the proposal, these two
interfaces will be extended with a new method:

org.apache.derby.iapi.sql.execute.NoPutResultSet#isCurrentPositionValid()  <- allows resultsets
to call their source resultsets for this info
org.apache.derby.iapi.store.access.ScanController#isCurrentPositionValid() <- allows resultsets
which access the ScanControllers to get this info from store layer

An alternative fix is to continue calling source.getCurrentRow(), however that will mean that
the row gets requalified before the update (-> reintroduces the problems of DERBY-1087).

Please let me know if anyone has better aproaches of solving this issue.


> positioned updates and deletes allowed after a commit without repositioning the cursor
- if the table is indexed on the columns selected
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-1361
>          URL: http://issues.apache.org/jira/browse/DERBY-1361
>      Project: Derby
>         Type: Bug

>   Components: JDBC
>     Versions: 10.2.0.0
>  Environment: Java 1.4
>     Reporter: Andreas Korneliussen
>     Assignee: Andreas Korneliussen

>
> After a commit, the cursor should be positioned before the next row (not on a row). However
in Derby 10.2, I now see the following behavior if the table has an index on the selected
columns:
> ij> create table t (id int primary key);
> ij> commit;
> ij> insert into t values 1,2,3,4,5,6,7,8,9;
> 9 rows inserted/updated/deleted
> ij> commit;
> ij> get cursor c1 as 'select * from t for update';
> ij> next c1;
> ID         
> -----------
> 1          
> ij> commit;
> ij> update t set id=id+1000 where current of c1;
> 1 row inserted/updated/deleted
> ij> commit;
> ij> update t set id=id+1000 where current of c1;
> 1 row inserted/updated/deleted
> ij> 
> The expected behavior is  that the UPDATE .. WHERE CURRENT OF fails with:
> ERROR 24000: Invalid cursor state - no current row.
> The problem applies to both scrollable and forward-only updatable cursors.
> Note: If the table is created *without* the index, I do see the expected behavior.
> I am marking this as a regression, since this issue is not reproducible on older, released
versions of derby (I have tested with 10.1.2.1).

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


Mime
View raw message