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] Updated: (DERBY-1251) cancelRowUpdates() affects rows updated with updateRow() in scrollable updatable resultsets
Date Mon, 08 May 2006 08:27:21 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1251?page=all ]

Andreas Korneliussen updated DERBY-1251:

    Attachment: DERBY-1251v2.diff


In this patch (DERBY-1251v2.diff) I have addressed the problem in that
updateXXX(..) methods get to write directly into data which is owned
by theResultSet. The old behavior was that updateXXX() wrote directly
into currentRow(..), and a copy of the old data in current row was put
into copyOfDatabaseRow, to support cancelRowUpdates.

The new logic is that the updateXXX(..) methods will write into a
new ExecRow attribute in EmbedResultSet, called updateRow, and it is
no longer necessary to copy data into copyofDatabaseRow.

When doing updateRow() or insertRow(), the values are collected from
updateRow instead of currentRow. When doing cancelRowUpdates(), the
relevant flags are reset.

These changes has allowed me to remove the following attributes from

 * ExecRow insertRow
 * ExecRow currentRowBeforeInsert
 * DataValueDescriptor[] rowData
 * DataValueDescriptor[] copyOfDatabaseRow;

A new field has been added instead: 
 * ExecRow updateRow

All getXXX() methods use a method to look up a DataValueDescriptor for
the column. The getColumn() method will either return a
DataValueDescriptor from currentRow if the column has not been updated
with updateXXX(). Otherwise it will return the column from updateRow.
If on insertRow, the DataValueDescriptor is located from the
updateRow attribute.  

The patch still (as in previous patch DERBY-1251.diff) reload data
from the cursor at the end of updateRow and deleteRow. This is done by
calling movePosition() equal to relative(0).  

Client changes:
Similar as in DERBY-1251.diff: reload the data of the row after
updateRow(). Note that reloading the data from the cursor, causes an
extra roundtrip to the server. So this part can be improved. In
deleteRow() I am using updateCount_ to check if the row was deleted by
the cursor. This is also used in updateRow(), to see if it is necessary to 
reload data from the cursor.

SURTest: 4 testcases added.
The test passes, and I did not get any failures in derbyall.

> cancelRowUpdates() affects rows updated with updateRow() in scrollable updatable resultsets
> -------------------------------------------------------------------------------------------
>          Key: DERBY-1251
>          URL: http://issues.apache.org/jira/browse/DERBY-1251
>      Project: Derby
>         Type: Bug

>   Components: JDBC, Network Client
>     Versions:
>     Reporter: Andreas Korneliussen
>     Assignee: Andreas Korneliussen
>     Priority: Minor
>  Attachments: DERBY-1251.diff, DERBY-1251.stat, DERBY-1251v2.diff, DERBY-1251v2.stat,
> If an application does the following:
> rs.updateInt(1, newValueCol1);
> rs.updateRow();
> rs.updateInt(2, newValueCol2);
> rs.cancelRowUpdates();
> Then, when calling rs.getInt(1), it will return the old value. Instead it should return
the new value.
> Workaround: after calling rs.updateRow(), the application could call rs.relative(0).
> This problem does not affect forward only resultsets, since after an updateRow() they
get positoned before the next row, leaving it impossible to do anything with the current row.

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