Re: Triggering change notifications when modifying custom object ivars in core data app
Re: Triggering change notifications when modifying custom object ivars in core data app
- Subject: Re: Triggering change notifications when modifying custom object ivars in core data app
- From: Ben Trumbull <email@hidden>
- Date: Thu, 28 May 2009 13:20:24 -0700
On May 28, 2009, at 11:59 AM, Rick Hoge wrote:
Ben, Quincey, Sean, thanks for the comments. Maybe there are some
lower level design issues to rethink.
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.
The core data app I'm working on manages a database of images, and
is also supposed to allow construction of a sequence of image
processing operations. A processing operation is implemented as an
instance of an 'operation' class (loaded as plugins which must be
shared with non-core-data apps), which has a dictionary of input
parameters and output values (similar to an Image Unit). In
general, the core data app does not know what kind of input
parameters will be supported by the 'operation' objects it has to
represent, although these are always contained in a mutable
dictionary. This means that the core data app can't really provide
getters and setters because the actual parameter names (dictionary
keys) are not known until run time.
In the core data app, I am creating an entity to represent an
operation, with the actual operation object as a custom attribute
(as per the docs). The user can change the input parameters in the
object's dictionary of inputs, and this should be reflected in the
persistent store of corresponding to the custom attribute on disk.
I realize this is ugly, but I can't think of any other way to do it
given that the available operation classes are loaded as plugins at
run time.
In your description, there still doesn't seem to be any reason to
avoid copying the dictionary and setting a new immutable one.
Dictionary copies are shallow, so it's just the dictionary itself that
is a new copy. So even if the values were gigantic images, this is
still light weight.
That's your best bet. As I mentioned previously, you could also use
KVC and its undefined key support to add custom handling for keys not
known until run time.
Or as Kyle suggested, you could model this formally with a Parameter
entity.
- 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