Re: willChangeValueForKey, Ivars and Core Data
Re: willChangeValueForKey, Ivars and Core Data
- Subject: Re: willChangeValueForKey, Ivars and Core Data
- From: Jim Correia <email@hidden>
- Date: Tue, 20 Sep 2005 12:33:52 -0400
On Sep 19, 2005, at 11:05 PM, Scott Ahten wrote:
How would CoreData know whether or not your transient attribute
has any persistent attributes derived from it? (This information
cannot be expressed in the model.)
By "dependent" I mean that none of my CoreData persistent
properties are dependent on my iVar by triggering change
notifications for persistent attributes in KVO when calling....
I was talking about a different kind of dependence. If a persistent
attribute depends on a transient attribute, changing a transient
attribute must mark the object dirty so that the context knows it
needs to write it out in the future. Depending on the pattern used,
the persistent attribute may not be updated until willSave time.
Setting a breakpoint on didChangeValueForKey runs into the depths
of NSManagedObject, which is difficult to interpret. The document
never seems to become dirty until the method call is complete.
However, after implementing a custom version of - (void)
updateChangeCount:(NSDocumentChangeType)changeType for my document,
It appears that [NSUndoManager endUndoGrouping] is posting a
notification though NSNotifiationCenter, which is calling
updateChangeCount on my document. What's odd is that this
notification is only sent after I call will/didChangeValueForKey
*and* click on my application or attempt to save using CMD+S. If I
do not interact with my application, the notification is not
immediately posted after will/did is actually called though the
thread from NSTimer.
I wrote a little test app and poked around. It looks like (can't be
100% certain since I don't have the CoreData source :-) any
willChangeValueForKey/didChangeValueForKey will cause CoreData to
record a snapshot of the object on the undo stack, even if the passed
in key is not a modeled attribute.
This feels wrong to me - you should probably file a bug. (If it is
behaving correctly, perhaps we'll find out why.)
If you disable undo registration in your setter, then the document
won't be marked dirty, but you'll get a "phantom" undo state which
does nothing, and the document *is* marked dirty on redo.
I'm not sure what the workaround is, if any.
Jim
_______________________________________________
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