[Hibernate-issues] [Hibernate-JIRA] Assigned: (HB-182) dirtyProperties array incorrect following Interceptor.onFlushDirty

[<leg...@at...>]

Message:

   The following issue has been re-assigned.

   Assignee: Gavin King (mailto:ga...@in...)
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-182


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-182
    Summary: dirtyProperties array incorrect following Interceptor.onFlushDirty
       Type: Bug

     Status: Assigned
   Priority: Major

    Project: Hibernate2
   Versions:
             2.0.1

   Assignee: Gavin King
   Reporter: Tom Ward

    Created: Fri, 11 Jul 2003 2:54 AM
    Updated: Fri, 11 Jul 2003 11:44 PM

Description:
As Simon Spero noted in issue HB-4, in SessionImpl.flushEntities, the dirtyProperties array is calculated before Interceptor.onFlushDirty is called.  As onFlushDirty has no way of reporting which of the currentState properties it has changed, if onFlushDirty does change a property, the dirtyProperties array will be incorrect.  This seems to be an issue in the following scenario -

A superclass Super defines an id and a dateModified property, while a subclass Sub defines a commentText property.  Sub is mapped as a joined-subclass of Super.  An Interceptor is written to change the dateModified property in the currentState to the current date, whenever onFlushDirty is called.

The issue is this - if commentText is changed and the object is flushed, the Interceptor correctly modifies the dateModified.  This change makes its way back to the instance of Sub, as expected.  However, when the time comes to update the object in the database, only the commentText is updated.  I believe that this is because as a joined-subclass, Sub is mapped across two tables, but the dirtyProperties array, calculcated before the call to onFlushDirty, only shows a change affecting one of these tables.

The ways I've found to work-around this are -

1) If using Interceptors, use a mapping strategy other than joined-subclasses.

2) Implement Interceptor.findDirty to return the properties you know will change in onFlushDirty (if other properties are dirty too).  This seems very awkward.

For me, the ideal solution would be to change the return type of Interceptor.onFlushDirty to an int[], indicating the properties which have been changed.  Then it would be a simple task to calculate the union of this array and dirtyProperties (and maybe even recheck the intersection).

I hope this is all helpful - I have read and re-read the javadocs to try and make sure I'm not missing anything, but it is still possible.  I'll give as much help as I can trying to fix this.


---------------------------------------------------------------------
JIRA INFORMATION:
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

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira