site_archiver@lists.apple.com Delivered-To: cocoa-dev@lists.apple.com So I have a CoreData app (10.5.5, 64 bit only) that has a NSManagedObject that has an NSColor* that is part of its data model. Because this color is actually a computed value that we want to cache, it is declared as a property: @property (retain) NSColor* color; but since we may need to calculate it, we also map it to an instance variable _color: @synthesize color = _color; // we actually implement both setter and getter - should we stil declare this? The best place is in the -awake* methods, specifically -awakeFromFetch In other words, I read my document off of disk, and CoreData magically makes sure that my "color" property is set. But since it never seems to call my setColor: setter thought that perhaps if I just observed when the "color" property changed, I could fire then: but that code never seems to fire either. Digging into the documentation some more, it seemed that implementing this might do the trick: - (void)setPrimitiveValue:(id)value forKey:(NSString *)key { if ([key isEqualToString:@"color"]) { [self setColor:value]; return ; } [super setPrimitiveValue:value forKey:key]; } Uhm ... the documentation says: - Ben _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/site_archiver%40lists.apple... ... this doesn't follow. That you need to calculate it doesn't mean it has to be in an ivar. Modeled properties should never be declared synthesized. (a) pointless (b) unhappy The problem I have is that I want to cache the components of the color as well (as separate CGFloat properties) I have the feeling this is your only actual problem, and everything else would go away if you just used the standard modeled properties conventions. You should also have a custom setColor public setter for when you update the value. Core Data won't call that because Core Data doesn't update your values, you do. Correct. Core Data rarely uses the public accessor methods. Those are for you and your client code. Semantically "initializing" the object from the database values and "setting a new value" are very different operations. Exactly. The values have not changed. Ideally, there should never be KVO notifications from an object simply being restored/initialized. There are still some places where practically and ideally don't yet meet, but we do try to not issue superfluous notifications. "you therefore absolutely must not override: primitiveValueForKey:, setPrimitiveValue:forKey:" Try Dave's suggestions about using transformable properties, and the references to the custom accesors. This email sent to site_archiver@lists.apple.com