On Mar 30, 2014, at 18:38 , Rick Mann <rm...@latencyzero.com> wrote:
> The docs about custom attributes show backing those transient attributes with
> an iVar as a cache, and then writing or reading from the "real" attribute
> either during access or during fetch/save (as you mention in 4a&b). I don't
> bother with the iVar, as it seemed unnecessary, but maybe Core Data is
> looking for accesses to that?
In the documentation:
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CoreData/Articles/cdNSAttributes.html
the example shows a transient attribute (“color”) of type NSColor* and a
persistent attribute (“colorData”) of type NSData*. Note that the “color”
property maintains its own backing store (via “primitiveColor”), as well as the
backing store of “colorData”. It’s a side-effect of this strategy that the
“color” backing store isn’t nil when the “color” property has a non-nil value,
and that’s the part that you didn’t implement.
[Of course, the “color" property can’t be saved because it’s a type unknown to
Core Data, but that never happens because the attribute is transient.]
However, Jerry’s excellent advice about making properties optional is probably
a better way to solve this particular case.
_______________________________________________
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
