On 2015 Jan 26, at 16:10, Richard Charles <rcharles...@gmail.com> 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 (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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
