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

Reply via email to