Re: CoreData: Using willSave to update timestamps causes hang?
Re: CoreData: Using willSave to update timestamps causes hang?
- Subject: Re: CoreData: Using willSave to update timestamps causes hang?
- From: Jesse Grosjean <email@hidden>
- Date: Fri, 3 Jun 2005 10:05:10 -0400
Jim,
Is there a recommended way for keeping a last saved date attached to
individual entities then? The last saved date may or may not be
displayed in the UI at any given time.
If I change the requirements to be the last edit time, I suppose I
could catch the edits via a setValue:forKey override and make sure
the key isn't the timestamp key (and that we aren't in the middle of
an undo or redo.) Are there gotchas with this approach? Bad idea?
Anyone doing something similar?
Was a good solution ever found for this? I'm running into a similar
problem using NSPersistentDocument, I would like the UI to indicated
if my managed objects are (edited) have unsaved changes. Ideally I
would like to implement isEdited like this:
- (BOOL)isEdited {
return [[self changedValues] count] > 0;
}
The problem is I don't know how to trigger KVC notifications for this
property (so the UI is updated) without core data taking notice and
doing things like dirtying the document's isDocumentEdited status or
adding extra undo invocations.
It seems like anytime the methods willChangeValueForKey and
didChangeValueForKey are called core data will take notice, even if
the key is not declared in the core data model. Is it possible to
make core data ignore these changes?
Or is there a better approach for maintaining an isEdited status for
managed objects?
Thanks,
Jesse
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden