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: Richard Charles <email@hidden>
- Date: Tue, 27 Jan 2015 11:21:46 -0700
> On Jan 27, 2015, at 2:24 AM, Quincey Morris <email@hidden> wrote:
>
> Clearly, all this customization takes some coordination between steps 1 and 2, even if it’s just to know which of them needs to be customized in any particular case, and how. That where the documentation falls down — it gives recipes for a couple of scenarios, without helping you understand how to figure out other scenarios.
I tried really hard to get Core Data to work out of the box for this application but ran into the following difficulties:
1. Support for scalars (including C structs).
2. With large data sets KVO can be really slow.
In attempting to work around and work with these issues I discovered that during undo/redo only the primitive accessor is called. I also discovered a lot of other things. Also as Mike Abdullah pointed out Core Data *does* fire KVO notifications during undo/redo. It just doesn’t do it inside the primitive accessor.
This whole primitive/public accessor thing can be very confusing. As Quincey Morris pointed out the purpose of the primitive accessor is to provide access to the private internal backing store of the managed object. This is an “Associative Storage” design pattern. (Refer to Cocoa Design Patterns by Buck and Yacktman.) Keary Suska also points out another reason for the primitive accessor is for setting an objects values without causing KVO or change notifications to be sent.
You can’t override a primitive accessor because one is dynamically generated for you at runtime if it is needed. If a custom primitive accessor is implemented then the managed object subclass must provide an ivar for backing storage. The custom primitive accessor can’t use Apple’s backing store because the private internal store used by Core Data for managed objects is not exposed.
Primitive accessors are not mandatory. In fact Core Data does *not* dynamically generate primitive accessor methods if the attribute is defined as an instance variable. http://goo.gl/vNFvZ This makes sense. Why would Core Data dynamically generate a primitive accessor using the storage of your custom subclass? Apple’s documentation illustrates this for a scalar attribute value.
As Jerry Krinock pointed out Core Data does undo/redo very reliably and I certainly need undo with this application. However customizing Core Data for this application has been a challenge to say the least. The documentation is extensive and accurate but you have to wade through the swamp and back to appreciate what the documentation is saying. You also have decide how far off the beaten path you want to travel and whether to do so is wise. You also need to occasionally consider if you are traveling in the right direction, which is how this thread started. Thanks to all for the insight and suggestions.
Richard Charles
_______________________________________________
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