[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1564) Possible bug with deleting versioned object (patch included)

[Gail B. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1564?page=comments#action_22540 ] 

Gail Badner commented on HHH-1564:
----------------------------------

I noticed that the proposed change to CollectionType.isdirty(Object old, Object current, boolean[] checkable, SessionImplementor session), as it stands, applies only to Hibernate 3.1. The method will not be called in Hibernate 3.0.5 without making other changes because the superclass does not have this method.

I have also verified that applying the fix to hibernate 3.1 seems to work, but it causes unit test org.hibernate.test.legacy.FooBarTest.testVersionedCollections to fail as follows:

Testcase: testVersionedCollections took 0.146 sec
       FAILED
versioned collection before
junit.framework.AssertionFailedError: versioned collection before
       at org.hibernate.test.legacy.FooBarTest.testVersionedCollections(FooBarTest.java:3042)
       at org.hibernate.test.TestCase.runTest(TestCase.java:150)

This failure does not occur using the 3.1 code without this fix.

It seems strange to update a versioned entity without incrementing the version number. It also does not make sense to increment the version number for a delete, since it is the n-th version being deleted, not the (n+1)-th version. I have also verified that updates to an entity's collection are not cascaded if that entity is deleted in the same transaction as the update, so I'm not sure how a collection could ever dirty an entity on a delete requiring an update.

A possible workaround for this issue is to modify the trigger. Since triggers have access to the new and old values for the row, it could be changed to write to the audit table only when the new and old values are different. This may or may not be acceptable for a particular situation but maybe this could work in your case.

This comment will also be entered on the forum.

Gail Badner
SourceLabs, Inc.
Dependable Open Source Systems


> 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

>
>
> 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=collectiontype+isdirty
> 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.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira