[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1564?page=c...
]
Steve Ebersole commented on HHH-1564:
-------------------------------------
This one comes down to a descrepency between the state as built by the DeleteEventListener
(EntityEntry.deletedState) and the current values built during flush. Namely, the
deletedState does not account for collections. Well, it would except that
EntityPersister.getPropertyUpdateability() tells it to ignore them.
The solution is to not rely on property-updateability when building an entity's
deletedState. Conversely, I guess, we could also account for property-updateability when
buidling current-values in the flush listener.
I have not been able to recreate the issue of extra updates fired by inserting a parent.
Possible bug with deleting versioned object (patch included)
------------------------------------------------------------
Key: HHH-1564
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1564
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.1.2
Environment: 3.1rc2
Reporter: N Clayton
Assignee: Steve Ebersole
Fix For: 3.2.1
Attachments: onetomanydelete_test.tar.gz
We're seeing an odd problem when trying to delete a row. The code that does this
simply creates a new object, commits it, starts a new session, finds the object, deletes
it. It dies with a constraint violation on an audit table, because hibernate is issuing an
unnecessary update operation (and not incrementing the version either). Further debugging
shows that Hibernate thinks that three properties on the object are 'modified'.
These three are collections. One is the points collection, one owners and the other is
systems. Hibernate seems to think that they are 'different' because null != an
empty collection. So, it thinks it needs to update the object. However; later on - it
doesn't increment the version number - because it knows the object is to be deleted.
Thus - a problem.
A complete description is here:
http://forum.hibernate.org/viewtopic.php?t=950225&highlight=collectio...
This appears to be fixed if we change CollectionType.isDirty() to be:
public boolean isDirty(Object old, Object current, boolean[] checkable,
SessionImplementor session)
throws HibernateException {
if(checkable.length == 0) {
// Assume not checkable
return false;
}
return isDirty(old, current, session);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira