Actually IIRC we did allow to do arbitrary modifications to objects
within "validate*" at some point. And checking the code, I see where
you getting this exception now.
Could you please submit a bug report? It should be fairly easy to fix
it (although it will add a bit of overhead on commit, as we will have
to copy dirty objects in a separate collection). Also this time
around we'll try to add a unit test, so that it doesn't get lost
again :-)
Andrus
On Nov 27, 2006, at 12:31 PM, Bryan Lewis wrote:
We have some code in a DataObject's validateForUpdate() method that
modifies the object's relationships. It had been working fine for
over
a year, although it's not exercised very often because it's only
called
when an employee leaves. Today it threw a ConcurrentModification, so
I'm guessing there was some related change in Cayenne in the last few
months. It reminds me of the guideline we used to follow with our old
WebObjects apps, shouldn't modify an object in -validateForSave...
maybe
now that's a good rule in Cayenne too?
public void validateForUpdate(ValidationResult validationResult)
{
DataContext dc = getDataContext();
DataRow oldData =
dc.getObjectStore().getSnapshot(this.getObjectId());
Boolean oldIsActive = (Boolean) oldData.get("ISACTIVE");
Boolean newIsActive = getIsActive();
// If the employee is being made inactive...
if (oldIsActive.equals(Boolean.TRUE) &&
newIsActive.equals(Boolean.FALSE)) {
// Clear the employee's roles.
// Use a ListIterator to allow concurrent modification.
for (ListIterator it = getRoles().listIterator();
it.hasNext(); ) {
Role role = (Role) it.next();
it.remove();
removeFromRoles(role);
}
}
}
The exception:
org.objectstyle.cayenne.access.ObjectStoreGraphDiff.validateAndCheckNo
op(ObjectStoreGraphDiff.java:109)
org.objectstyle.cayenne.access.DataContext.flushToParent
(DataContext.java:1244)
org.objectstyle.cayenne.access.DataContext.commitChanges
(DataContext.java:1165)
This is with Cayenne 1.2.1.
