|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
Few other thoughts. Tried to catch up with you on IRC but you weren't around and I wanted to make sure I got my thoughts down.
1) Not a fan of the name DirtyTracker. Not sure what the right name is. What we have is a contract (interface) for an entity that says it will track its own state change and will allow Hibernate to hook into that for use in finding dirty entities as part of a flush. SelfDirtinessTracker? InLineDirtinessTracker? ITrackMyOwnStateChangesHibernateCanUseThatForDirtyChecking?
2) ITrackMyOwnStateChangesHibernateCanUseThatForDirtyChecking (or whichever other interface name that ends up upsetting this one in the voting) will need an additional method reset() to allow Hibernate to signal the tracker to reset its dirtiness (after its changes have been written to the database).
3) In terms of where to hook in the calls to ITrackMyOwnStateChangesHibernateCanUseThatForDirtyChecking, I'd suggest finding all the usages of the CustomEntityDirtinessStrategy methods. Tests aside, all those methods have just a single call each except for resetDirty which had 2 usages.