You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Andreas Korneliussen (JIRA)" <de...@db.apache.org> on 2006/04/25 11:30:07 UTC
[jira] Created: (DERBY-1251) cancelRowUpdates() affects rows
updated with updateRow() in scrollable updatable resultsets
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: 10.2.0.0
Reporter: Andreas Korneliussen
Assigned to: Andreas Korneliussen
Priority: Minor
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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1251) cancelRowUpdates() affects rows
updated with updateRow() in scrollable updatable resultsets
Posted by "Fernanda Pizzorno (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1251?page=comments#action_12378628 ]
Fernanda Pizzorno commented on DERBY-1251:
------------------------------------------
Review:
The patch looks good, here are some comments:
Index: java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java
===================================================================
@@ -180,10 +181,17 @@
[...]
+ /* updateRow is used to keep the values which are updated with updateXXX()
+ * calls. It is by both insertRow() and updateRow().
^ used
+ * It is initialized to null if the resultset is not updatable.
+ */
[...]
+ /* These are the columns which have been updated so far.
+ * Used to build UPDATE...WHERE CURRENT OF sql and
*** could this be removed?
+ * INSERT INTO .. statements.
+ */
@@ -240,14 +248,26 @@
[...]
+ columnGotUpdated = new boolean[columnCount];
+ updateRow = factory.getValueRow(columnCount);
+ for (int i = 1; i <= columnGotUpdated.length; i++) {
+ updateRow.setColumn(i, resultDescription.getColumnDescriptor(i).
+ getType().getNull());
+ }
+ initializeUpdateRowModifiers();
+ } else {
+ updateRow = null;
Could you use columnCount instead of columnGotUpdated.length on the third line?
There is a mix of tab and spaces being used on these rows.
@ -289,14 +309,18 @@
// onRow protects us from making requests of
// resultSet that would fail with NullPointerExceptions
// or milder problems due to not having a row.
[...]
+ protected final void checkOnRow() throws SQLException {
+ if (currentRow.getRowArray() == null) {
throw newSQLException(SQLState.NO_CURRENT_ROW);
+ }
+ }
This comments should be updated to reflect what is done in the method.
[...]
+ /**
+ * Initializes the updateRow and columnGotUpdated fields
+ */
+ private void initializeUpdateRowModifiers() {
+ currentRowHasBeenUpdated = false;
+ Arrays.fill(columnGotUpdated, false);
}
This comment should also be updated, updateRow is not being initialized.
[...]
@@ -3598,15 +3620,19 @@
}
rs.close();
rs.finish();
- //After a delete, the ResultSet will be positioned right before
- //the next row.
- rowData = null;
- currentRow = null;
+ //For forward only resultsets, after a delete,
+ // the ResultSet will be positioned right before the next row.
+ if (getType() == TYPE_FORWARD_ONLY) {
+ currentRow.setRowArray(null);
+ } else {
+ movePosition(RELATIVE, 0, "relative");
+ }
According to JDBC 3.0 specification section "14.2.4.2 Deleting a Row", after a
deleteRow has been called, the cursor will be positioned before the next valid
row. Is there a reason to make this comment specific to forward only result
sets?
Index: java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/SURTest.java
===================================================================
@@ -242,6 +242,218 @@
verifyTuple(rs);
assertFailOnUpdate(rs);
}
+
+ /**
+ * Test that you can correctly run multiple updateXXX() + updateRow()
+ * combined with cancelRowUpdates().
+ */
+ public void testMultiUpdateRow1()
+ throws SQLException
+ {
[...]
+ assertEquals("Expected the resultset detect the updates of previous" +
+ "updateRow after cancelRowUpdates", newCol2, rs.getInt(2));
+ assertEquals("Expected the resultset detect the updates of previous" +
+ "updateRow after cancelRowUpdates", newCol2, rs.getInt(2));
I guess the intention was to check column 2 and 3 and not twice column 2.
+ assertTrue("Expected rs.rowUpdated() to be true after " +
+ "updateRow and cancelRowUpdates", rs.rowUpdated());
+
+ rs.close();
+ }
+
+ /**
+ * Test that you can correctly run multiple updateNull() + updateRow()
+ * combined with cancelRowUpdates().
+ */
+ public void testMultiUpdateRow2()
+ throws SQLException
+ {
[...]
+ assertEquals("Expected the resultset detect the updates of previous" +
+ "updateRow after cancelRowUpdates", 0, rs.getInt(2));
+ assertEquals("Expected the resultset detect the updates of previous" +
+ "updateRow after cancelRowUpdates", 0, rs.getInt(2));
Same here.
+ assertTrue("Expected rs.rowUpdated() to be true after " +
+ "updateRow and cancelRowUpdates", rs.rowUpdated());
+
+ rs.close();
+ }
+
+ /**
+ * Test that you get cursor operation conflict warning if updating
+ * a row which has been deleted from the table.
+ */
> 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: 10.2.0.0
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
> Priority: Minor
> Attachments: DERBY-1251.diff, DERBY-1251.stat, DERBY-1251v2.diff, DERBY-1251v2.stat, derbyall_report.txt, derbyall_report.txt
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1251) cancelRowUpdates() affects rows updated
with updateRow() in scrollable updatable resultsets
Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1251?page=all ]
Andreas Korneliussen closed DERBY-1251:
---------------------------------------
Thanks for committing this patch. Closing the report.
> 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: 10.2.0.0
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: DERBY-1251.diff, DERBY-1251.stat, DERBY-1251v2.diff, DERBY-1251v2.stat, DERBY-1251v3.diff, derbyall_report.txt, derbyall_report.txt
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1251) cancelRowUpdates() affects rows
updated with updateRow() in scrollable updatable resultsets
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1251?page=comments#action_12378922 ]
Knut Anders Hatlen commented on DERBY-1251:
-------------------------------------------
I will run some tests and commit the patch.
> 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: 10.2.0.0
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
> Priority: Minor
> Attachments: DERBY-1251.diff, DERBY-1251.stat, DERBY-1251v2.diff, DERBY-1251v2.stat, DERBY-1251v3.diff, derbyall_report.txt, derbyall_report.txt
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1251) cancelRowUpdates() affects rows
updated with updateRow() in scrollable updatable resultsets
Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1251?page=all ]
Andreas Korneliussen updated DERBY-1251:
----------------------------------------
Attachment: derbyall_report.txt
Attaching report from derbyall, with patch DERBY-1251v2.diff
> 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: 10.2.0.0
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
> Priority: Minor
> Attachments: DERBY-1251.diff, DERBY-1251.stat, DERBY-1251v2.diff, DERBY-1251v2.stat, derbyall_report.txt, derbyall_report.txt
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1251) cancelRowUpdates() affects rows
updated with updateRow() in scrollable updatable resultsets
Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1251?page=all ]
Andreas Korneliussen updated DERBY-1251:
----------------------------------------
Attachment: DERBY-1251.diff
DERBY-1251.stat
derbyall_report.txt
Changes to address this bug:
Embedded JDBC driver:
EmbedResultSet.java:
* at the end of updateRow/deleteRow, the rowdata in the resultset is reloaded from the cursor
Client JDBC driver:
ResultSet.java:
* removed the use of updateRowCalled_
* at the end of updateRowX/deleteRowX, the rowdata is reloaded from the cursor
Tests:
SURTest.java
* 3 testcases added, covering both this issue, and the DERBY-1249.
Note: by reloading the rowdata from the cursor, this fix also fixes issue DERBY-1249, therefore these tests are part of this fix.
> 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: 10.2.0.0
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
> Priority: Minor
> Attachments: DERBY-1251.diff, DERBY-1251.stat, derbyall_report.txt
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1251) cancelRowUpdates() affects rows
updated with updateRow() in scrollable updatable resultsets
Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1251?page=all ]
Andreas Korneliussen updated DERBY-1251:
----------------------------------------
Derby Info: [Patch Available]
> 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: 10.2.0.0
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
> Priority: Minor
> Attachments: DERBY-1251.diff, DERBY-1251.stat, derbyall_report.txt
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1251) cancelRowUpdates() affects rows
updated with updateRow() in scrollable updatable resultsets
Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1251?page=comments#action_12376218 ]
Andreas Korneliussen commented on DERBY-1251:
---------------------------------------------
The bug was detected while adding the following testcase in SURTest:
/**
* Test that you can correctly run multiple updateXXX() + updateRow()
* combined with cancelRowUpdates().
*/
public void testMultiUpdateRow1()
throws SQLException
{
Statement s = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_UPDATABLE);
s.setCursorName(getNextCursorName());
ResultSet rs = s.executeQuery("select * from t1");
rs.absolute(5);
final int oldCol2 = rs.getInt(2);
final int newCol2 = -2222;
final int oldCol3 = rs.getInt(3);
final int newCol3 = -3333;
rs.updateInt(2, newCol2);
assertEquals("Expected the resultset to be updated after updateInt",
newCol2, rs.getInt(2));
rs.cancelRowUpdates();
assertEquals("Expected updateXXX to have no effect after cancelRowUpdated",
oldCol2, rs.getInt(2));
rs.updateInt(2, newCol2);
assertEquals("Expected the resultset to be updated after updateInt",
newCol2, rs.getInt(2));
assertTrue("Expected rs.rowUpdated() to be false before updateRow",
!rs.rowUpdated());
rs.updateRow();
assertTrue("Expected rs.rowUpdated() to be true after updateRow",
rs.rowUpdated());
==== FAILS HERE ======
assertEquals("Expected the resultset detect the updates of previous " +
"updateRow", newCol2, rs.getInt(2));
====================
rs.updateInt(3, newCol3);
assertEquals("Expected the resultset to be updated after updateInt",
newCol3, rs.getInt(3));
assertEquals("Expected the resultset detect the updates of previous " +
"updateRow", newCol2, rs.getInt(2));
rs.cancelRowUpdates();
assertEquals("Expected updateXXX to have no effect after " +
"cancelRowUpdated", oldCol3, rs.getInt(3));
assertEquals("Expected the resultset detect the updates of previous " +
"updateRow after cancelRowUpdated", newCol2, rs.getInt(2));
rs.updateInt(3, newCol3);
rs.updateRow();
assertEquals("Expected the resultset to be updated after updateInt",
newCol3, rs.getInt(3));
rs.cancelRowUpdates();
assertEquals("Expected the resultset detect the updates of previous" +
"updateRow after cancelRowUpdates", newCol2, rs.getInt(2));
assertEquals("Expected the resultset detect the updates of previous" +
"updateRow after cacnelRowUpdates", newCol2, rs.getInt(2));
assertTrue("Expected rs.rowUpdated() to be true after " +
"updateRow and cancelRowUpdates", rs.rowUpdated());
rs.close();
}
The test fails with:
1) testMultiUpdateRow1(org.apache.derbyTesting.functionTests.tests.jdbcapi.SURTest)junit.framework.AssertionFailedError: Expected the resultset detect the updates of previous updateRow expected:<-2222> but was:<4>
at org.apache.derbyTesting.functionTests.tests.jdbcapi.SURTest.testMultiUpdateRow1(SURTest.java:203)
...
> 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: 10.2.0.0
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
> Priority: Minor
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1251) cancelRowUpdates() affects rows
updated with updateRow() in scrollable updatable resultsets
Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1251?page=comments#action_12377466 ]
Andreas Korneliussen commented on DERBY-1251:
---------------------------------------------
Withdrawing the patch DERBY-1251.diff.
It turns out that the currentRow attribute in the EmbedResultSet may in certain combinations of scrolling refer directly to a row in the hashtable of a ScrollInsensitive ResultSet. updateXXX() methods then get to write into the hashtable. When doing cancelRowUpdates(), EmbedResultSet copies over its internal reference to the columns, however the data in the hashtable may still have been modified by updateXXX. This patch simply reveals this problem more clearly, as this situation may occur every time one do cancelRowUpdates. I will work on a patch to completely remove this problem.
> 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: 10.2.0.0
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
> Priority: Minor
> Attachments: DERBY-1251.diff, DERBY-1251.stat, derbyall_report.txt
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-1251) cancelRowUpdates() affects rows
updated with updateRow() in scrollable updatable resultsets
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1251?page=all ]
Knut Anders Hatlen resolved DERBY-1251:
---------------------------------------
Fix Version: 10.2.0.0
Resolution: Fixed
Committed revision 406279.
> 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: 10.2.0.0
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: DERBY-1251.diff, DERBY-1251.stat, DERBY-1251v2.diff, DERBY-1251v2.stat, DERBY-1251v3.diff, derbyall_report.txt, derbyall_report.txt
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1251) cancelRowUpdates() affects rows
updated with updateRow() in scrollable updatable resultsets
Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1251?page=all ]
Andreas Korneliussen updated DERBY-1251:
----------------------------------------
Derby Info: [Patch Available]
A patch (DERBY-1251v2.diff) is available for review.
> 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: 10.2.0.0
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
> Priority: Minor
> Attachments: DERBY-1251.diff, DERBY-1251.stat, DERBY-1251v2.diff, DERBY-1251v2.stat, derbyall_report.txt
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1251) cancelRowUpdates() affects rows
updated with updateRow() in scrollable updatable resultsets
Posted by "Fernanda Pizzorno (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1251?page=comments#action_12378902 ]
Fernanda Pizzorno commented on DERBY-1251:
------------------------------------------
All of my comments have been addressed. The patch DERBY-1251v3.diff looks good.
> 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: 10.2.0.0
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
> Priority: Minor
> Attachments: DERBY-1251.diff, DERBY-1251.stat, DERBY-1251v2.diff, DERBY-1251v2.stat, DERBY-1251v3.diff, derbyall_report.txt, derbyall_report.txt
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1251) cancelRowUpdates() affects rows
updated with updateRow() in scrollable updatable resultsets
Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1251?page=comments#action_12378856 ]
Andreas Korneliussen commented on DERBY-1251:
---------------------------------------------
> - //After a delete, the ResultSet will be positioned right before
> - //the next row.
> - rowData = null;
> - currentRow = null;
> + //For forward only resultsets, after a delete,
> + // the ResultSet will be positioned right before the next row.
> + if (getType() == TYPE_FORWARD_ONLY) {
> + currentRow.setRowArray(null);
> + } else {
> + movePosition(RELATIVE, 0, "relative");
> + }
>
> According to JDBC 3.0 specification section "14.2.4.2 Deleting a Row", after a
> deleteRow has been called, the cursor will be positioned before the next valid
> row. Is there a reason to make this comment specific to forward only result
> sets?
This is a good point. For FORWARD_ONLY resultsets, this means that the cursor is not on a row (i.e all getXXX(..) methods throws exception), and when calling next the cursor will be positioned on the next row.
For SCROLL INSENSITIVE cursors, I am a bit unsure if the current row (which has been deleted) is valid or not. If it is valid, it is correct to be on the current row, since it is before the next valid row. If it is considered as invalid the cursor should be position somewhere inbetween the current row and the next row (i.e not on a row).
Then the behavior would be that: calling next() will give the next row, calling previous will give the previous row, and calling relative(0) will give the current invalid (deleted) row in scroll insensitive resultsets.
However I choose to not deal with this in this patch. The call to movePosition(RELATIVE..) should not be part of the patch, it could be added in another patch, i.e if we choose to consider the current row as a valid row after it has been deleted.
> 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: 10.2.0.0
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
> Priority: Minor
> Attachments: DERBY-1251.diff, DERBY-1251.stat, DERBY-1251v2.diff, DERBY-1251v2.stat, derbyall_report.txt, derbyall_report.txt
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1251) cancelRowUpdates() affects rows
updated with updateRow() in scrollable updatable resultsets
Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1251?page=comments#action_12376245 ]
Andreas Korneliussen commented on DERBY-1251:
---------------------------------------------
Actually, the previous comment indicates another related bug: after updateRow(), rs.getXXX() returns the old value.
In addition I found that in the network driver: after doing updateRow(), and you later do updateXXX() + cancelRowUpdates(), the cancelRowUpdates() does not have any effect, since updateRow() had been called once on the row.
Due to this logic in org.apache.derby.client.am.ResultSet.cancelRowUpdates() :
/ if updateRow() has already been called, then cancelRowUpdates should have
// no effect. updateRowCalled_ is reset to false as soon as the cursor moves to a new row.
if (!updateRowCalled_) {
resetUpdatedColumns();
}
updateRowCalled_ is set to true in updateRow().
Seems most of this logic is relaxed on having the resultset becoming unpositioned after an updateRow().
> 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: 10.2.0.0
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
> Priority: Minor
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1251) cancelRowUpdates() affects rows
updated with updateRow() in scrollable updatable resultsets
Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1251?page=all ]
Andreas Korneliussen updated DERBY-1251:
----------------------------------------
Attachment: DERBY-1251v3.diff
Attached is a patch (DERBY-1251v3.diff) which addresses the review comments. The changes in deleteRow() behavior has been removed.
> 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: 10.2.0.0
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
> Priority: Minor
> Attachments: DERBY-1251.diff, DERBY-1251.stat, DERBY-1251v2.diff, DERBY-1251v2.stat, DERBY-1251v3.diff, derbyall_report.txt, derbyall_report.txt
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1251) cancelRowUpdates() affects rows
updated with updateRow() in scrollable updatable resultsets
Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1251?page=all ]
Andreas Korneliussen updated DERBY-1251:
----------------------------------------
Attachment: DERBY-1251v2.diff
DERBY-1251v2.stat
Embedded:
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
EmbedResultSet:
* 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.
Testing:
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: 10.2.0.0
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
> Priority: Minor
> Attachments: DERBY-1251.diff, DERBY-1251.stat, DERBY-1251v2.diff, DERBY-1251v2.stat, derbyall_report.txt
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1251) cancelRowUpdates() affects rows
updated with updateRow() in scrollable updatable resultsets
Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1251?page=all ]
Andreas Korneliussen updated DERBY-1251:
----------------------------------------
Derby Info: (was: [Patch Available])
> 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: 10.2.0.0
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
> Priority: Minor
> Attachments: DERBY-1251.diff, DERBY-1251.stat, derbyall_report.txt
>
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira