Re: Forcing Core Data to save attribute changed behind its back?
Re: Forcing Core Data to save attribute changed behind its back?
- Subject: Re: Forcing Core Data to save attribute changed behind its back?
- From: Sean McBride <email@hidden>
- Date: Tue, 24 Jul 2012 13:00:34 -0400
- Organization: Rogue Research Inc.
On Tue, 24 Jul 2012 15:15:16 +0200, Peter Hartmann said:
>What do you try to win by changing the attribute bind CD's back?
Run time performance. The data is large and changes frequently.
>If you want to take it out of undo you might switch it off temporarily
>(e.g. [undoManager disableUndoRegistration], or store the undo manager
>in a local, set the context's undo to nil, and restore it - which may or
>may not cause trouble depending on whats happening in your object graph.
>I use GCUndoManager to stay away from such trouble.)
In fact, I want undo, and to support it, I had to do extra work. (I use GCUndoManager too.) That's working fine. The problem is that saving doesn't save.
>Apart from that there is
>
>- (void)refreshObject:(NSManagedObject *)object mergeChanges:(BOOL)flag
From what I can tell from the docs, this is more to update the object *from* the store. I need the opposite: to convince Core Data to write my object's attributes to the store (when I invoke 'save').
>as well as the
>
>- (void)setPrimitiveValue:(id)value forKey:(NSString *)key
This doesn't trigger Core Data to think there is a change, and neither does regular accessors.
Thanks,
--
____________________________________________________________
Sean McBride, B. Eng email@hidden
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden