Specifically my entity has a 'transformable' attribute for which the values are a custom object class, and this object class has an ivar that is an NSMutableDictionary. The user can modify entries in this dictionary, and I would like this to cause the context to be flagged as dirty and to have the custom object flagged to be updated in the persistent store.
Attributes can only be effectively immutable value types. While it's fine to use any kind of NSDictionary with transformable properties, once it is assigned, we expect it to act immutable. We expect transfer of ownership, not side effects occurring out from underneath us. NSManagedObject owns all its attribute properties. The same thing is true for NSMutableString. There are no KVO notifications for hacking on its characters after setting it as a modeled property value.
This pattern is usually a flawed model design. If the properties are to be this independently mutable, then there should be a relationship, and/or the complex attribute should be decomposed into several attributes. This is, after all, a gross violation of encapsulation.
Issuing calls to will/didChange manually won't help since the property didn't change. will/didChange calls need to bracket the actual change. In theory, you could add a transient "generation count", and have every client who hacks on the mutable dictionary out from underneath your managed object increment it.
Hard to see what that buys you over, say, writing proper setters and getters for the sub-properties stored in the dictionary, and stop clients mutating the dictionary directly. Restore clean encapsulation.
For arbitrary keys, some people override -valueForUndefinedKey: Personally, I think that's rather skanky, but it appears to satisfy many. It would certainly work better than your current approach.
If you had intended it to work as a value type, mark the property as copy and use the dynamic setters, or make your custom setters perform a copy.
- 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
