re: Re: Triggering change notifications when modifying custom object ivars in core data app
re: Re: Triggering change notifications when modifying custom object ivars in core data app
- Subject: re: Re: Triggering change notifications when modifying custom object ivars in core data app
- From: Ben Trumbull <email@hidden>
- Date: Thu, 28 May 2009 11:25:03 -0700
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 (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