[
https://hibernate.onjira.com/browse/HHH-6998?page=com.atlassian.jira.plug...
]
Shawn Clowater commented on HHH-6998:
-------------------------------------
Steve,
You don't waste any time at all when you get an idea in your head. Took a peek at the
code and it looks very slick and I can't wait to kick the tires on it. From a cursory
glance it looks like it should fit the bill nicely.
The one scenario i'll have to go back and hammer to see if it even still exists is
where the core was trying to update a fk reference on a many to one to null on a delete.
In that case it was modifying the current values array w/o calling the setter on my entity
so I wasn't trapping the change. This may no longer apply as this was 2 or 3 years
ago at least when I was looking at that.
Expand CustomEntityDirtinessStrategy to define findDirty
--------------------------------------------------------
Key: HHH-6998
URL:
https://hibernate.onjira.com/browse/HHH-6998
Project: Hibernate ORM
Issue Type: Improvement
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 4.1.0
Time Spent: 3h 22m
{{CustomEntityDirtinessStrategy}} allows applications to bypass dirty checking in cases
when they know an entity is not dirty.
In some of these application, they also carry along the initial ("loaded")
state. In those cases it might be more performant to allow them to tell us which fields
changed. If we go this route though I'd like to take it as an opportunity to explore
options for not exposing all these arrays to user code. So partially this issue will be a
discussion of possible approaches to that.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira