Re: Detecting Managed Object Property Change From Undo Redo
Re: Detecting Managed Object Property Change From Undo Redo
- Subject: Re: Detecting Managed Object Property Change From Undo Redo
- From: Jerry Krinock <email@hidden>
- Date: Mon, 26 Jan 2015 17:55:12 -0800
On 2015 Jan 26, at 16:10, Richard Charles <email@hidden> wrote:
> It is not uncommon for this application to work with large data sets. I tested using KVO on a managed object property and undo took 34 seconds. I implemented custom accessors (public and primitive) containing custom change code and undo took 3 seconds.
Very interesting result.
> I have not tested using NSObjectsChangedInManagingContextNotification to see how long an undo would take but the thought looking through the notification for specific properties in specific objects seems daunting. I saved out the notification description for the change mentioned above and it was a 29 MB text file. So using notifications from the managed object context for this property change does not seem to be the way to go.
That’s probably true, but as you’ve found above, you never know about performance until you test it.
> It looks like using custom public and primitive accessors is the way go. Not for everything, but where it is needed.
OK, although I’ve never used them, there is a section on "Custom Primitive Accessor Methods” in the Core Data Programming Guide, and it does not say not to. The example they give is pretty confusing:
- (void)setPrimitiveInt16:(short)newInt16 {
nonCompliantKVCivar = newInt16;
}
What in the world is that nonCompliantKVCivar? I tried it in my project, on the ‘rating’ property as in my YouTube video.
- (void)setPrimitiveRating:(NSNumber*)newRating {
rating = newRating ;
}
Does not compile. The compiler never heard of ‘rating’. Same result if I change it to _rating, m_rating or nonCompliantKVCrating. OK, so then I added an ivar: _rating, and now of course
_rating = newRating ;
compiles. What was even more surprising is if I changed a ‘rating’ by clicking stars in the user interface, the user interface would not show the stars, until I closed and reopened the document; voila it had persisted!
So this instance variable is somehow tied to the persistent store. I suppose this is explained by this documentation snippet: "Typically there should be little reason to implement primitive accessor methods. They are, however, useful if you want custom methods to provide direct access to instance variables for persistent Core Data properties.”
The lack of action in the user interface is maybe explained by "they do not issue key-value access or observing notifications”. OK, the user interface runs on Cocoa Bindings which runs on KVO. But did my click not also run through the regular accessor, which does issue KVO? I set a breakpoint and confirmed that setRating: was indeed the invoker of setPrimitiveRating:.
One more thing I tried: This is an override. Should I not invoke super?
- (void)setPrimitiveRating:(NSNumber*)newRating {
rating = newRating ;
[super setPrimitiveRating:newRating] ;
}
Result: Compiler warning that my superclass (eventually, NSManagedObject) did not implement this method, a crash at runtime confirming that.
Conclusion: Primitive accessors are potentially useful but more study is needed to understand how they work, and in particular how to override them without breaking stuff.
_______________________________________________
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