]
Gail Badner updated HHH-2547:
-----------------------------
Attachment: HHH-2547-test.patch
Duplicate of HHH-2547.patch-test that is recognized as text. HHH-2547.patch-test can be
deleted.
Incorrect update strings when using rowid
-----------------------------------------
Key: HHH-2547
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2547
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.3
Environment: Oracle 10.2.0.1.0; Oracle JDBC 10.2.0.3
Reporter: Gail Badner
Priority: Minor
Attachments: HHH-2547-test.patch, HHH-2547.patch, HHH-2547.patch-test
The fix for HHH-2469 introduced a new bug when an update spans more than one table.
I've added a joined subclass, NamedPoint, to org.hibernate.test.rowid.RowIdTest and
added a new test that reproduces the problem. Using this test case, the fix for HHH-2469
results in the following update strings:
update Point set description=? where rowid=?
update Point set description=? where \"x\"=? and \"y\"=?
update NamedPoint set name=? where \"x\"=? and \"y\"=?
The first statement is the intended optimization for the second statement. This
optimization is supposed to replace the second (default) update statement.
Because the update spans two tables, AbstractEntityPersister.update() will only execute
the first and second statements. The update to subclass properties will not be executed.
The second statement will be omitted by replacing:
System.arraycopy( sqlUpdateStrings, 0, result, 1, getTableSpan() );
with:
if ( getTableSpan() > 1 ) {
System.arraycopy( sqlUpdateStrings, 1, result, 1, getTableSpan() - 1 );
}
Another problem cropped up when executing the test case that updates a NamedPoint. When
an entity is read, the rowid is correct, but by the time the update is done, the rowid is
somehow incremented and the query fails with "ORA-01410: invalid ROWID". In a
test, I verified that the rowid was "AAAUlSAAEAAAAOkAAA" when the entity when
read from the database, but the value that was bound to the prepared statement was
"AAAUlTAAEAAAAe0AAA". After the test failed, the rowid in the database is still
"AAAUlSAAEAAAAOkAAA". I have not figured out where or why the rowid is being
modified, but it makes it impossible to use this optimization when the update spans more
than one table.
I'll attach patches for AbstractEntityPersister and the updated test shortly.
Gail Badner
SourceLabs -
http://www.sourcelabs.com
Dependable Open Source Systems
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: