On May 22, 2009, at 12:00 AM, Aurélien Hugelé wrote:
The willSave method is not very well described. In particular, can
we use setValue:forKey: (or trigger change notifications) inside it?
It's not clear what setValue:forKey: has to do with it.
That apart, in general, the documentation strongly recommends against
using KVC. Since you clearly already have a custom class, you should
be using the accessor methods.
it seems that for *deleted* objects only, triggering change
notifications is now allowed.
Am I right ?
No.
** The error message is telling you what your problem is **:
Failed to process pending changes before save. The context is still
dirty after 100 attempts. ** Typically this recursive dirtying is
caused by a bad validation method, -willSave, or notification
handler. ** "
and a simple backtrace would probably have confirmed.
It's not clear why you regard this as "strange". Whatever you're
doing in willSave is causing further change propagation (marking your
object as dirty), which is resulting in willSave being invoked again,
which is causing further change propagation...
One of the more common reasons for this is:
- (void)willSave {
self.lastModifiedDate = [NSDate date];
...
}
It doesn't matter whether you invoke accessor methods or
setValue:forKey: within willSave -- you need to test to ensure that
values haven't changed, or haven't changed by more than a certain
amount, before modifying them so that you don't end up in an infinite
loop.
An alternative strategy is to perform updates in response to an
NSManagedObjectContextWillSaveNotification.
mmalc
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
