Expand CustomEntityDirtinessStrategy to define findDirty
Description
follows up on
is followed up by
Activity
Steve Ebersole February 9, 2012 at 6:22 AM
Closing for 4.1 release
Steve Ebersole February 9, 2012 at 2:55 AM
Definitely, lol
Shawn Clowater February 9, 2012 at 2:03 AM
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.
Steve Ebersole January 27, 2012 at 1:33 AM
DirtyCheckContext would need access to Session, so:
CustomEntityDirtinessStrategy.java
public interface CustomEntityDirtinessStrategy {
...
public void findDirty(DirtyCheckContext context, Object entity);
}plus a getSession method on DirtyCheckContext
Steve Ebersole January 26, 2012 at 8:01 AM
Here is an initial swag...
CustomEntityDirtinessStrategy.java
public interface CustomEntityDirtinessStrategy {
...
public void findDirty(DirtyCheckContext context, Object entity, Session session);
}DirtyCheckContext.java
public interface DirtyCheckContext {
public static interface AttributeContext {
public String getName();
public Type getType();
public Object getCurrentValue();
public Object getLoadedValue();
}
public static interface AttributeChecker {
public boolean isDirty(AttributeContext attributeContext);
}
public void doDirtyChecking(AttributeChecker attributeChecker);
}Application code is already implementing CustomEntityDirtinessStrategy. The only new requirement here is to implement AttributeChecker. As an example consider a case where we hold a map of changed values on the entity itself:
public class MyCustomEntityDirtinessStrategy implements CustomEntityDirtinessStrategy {
...
public void findDirty(DirtyCheckContext context, final Object entity, final Session session) {
context.doDirtyChecking(
new AttributeChecker() {
public boolean isDirty(AttributeContext attributeContext) {
return ( (DirtyTrackingEntity) entity ).getChangedValueMap().containsKey( attributeContext.getName();
}
}
);
}
}
CustomEntityDirtinessStrategyallows 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.