Smarter version of normal
saveChanges()
method. Overridden to support autoLocking and a bugfix from Lenny Marks, calls up Will/Did methods on ERXEnterpriseObjects and corrects issues with
flushCaches()
needing to be called on objects in the parent context when committing the child context to the parent. If the editing context is a child of the object-store coordinator---that is, it's not a nested context---this method behaves exactly the same as
EOEditingContext.saveChanges()
. Otherwise, this method looks over the changed objects in
ec
(
updatedObjects()
,
insertedObjects()
and
deletedObjects()
). The changed objects lists are filtered for instances of
ERXGenericRecord
. The order of operations then becomes:
- Call
processRecentChanges()
on the child context to propagate changes. - Lock the parent editing context.
- On the deleted objects list in the child editing context, call
flushCaches()
on each corresponding EO in the parent context. - Unlock the parent editing context.
- Call
saveChanges()
on the child, committing the child changes to the parent editing context. - Lock the parent editing context.
- On the objects that were updated or inserted in the child, call
flushCaches()
on each corresponding EO in the parent context. - Unlock the parent editing context.
The order of operations is a bit peculiar: flush deletes, save, flush inserts and updates. This is done because deletes must be flushed because there may be dependent computed state that needs to be reset. But following the delete being committed, the relationships to other objects cannot be relied upon so it isn't reliable to call flushCaches after the commit. It's not entirely correct to flush the deletes like this, but it's the best we can do.
This works around an issue in EOF that we don't get a merge notification when a child EC saves to its parent. Because there's no merge notification, flushCaches()
isn't called by the EC delegate and we're essentially screwed vis-a-vis resetting computed state.
This method assumes that the ec
is locked before this method is invoked, but this method will take the lock on the parent editing context if the ec
is a nested context before and after the save in order to get the objects and to flush caches on them.