Re: CoreData - re-faulting object and removing self-observers results in messages being sent to zombie
Re: CoreData - re-faulting object and removing self-observers results in messages being sent to zombie
- Subject: Re: CoreData - re-faulting object and removing self-observers results in messages being sent to zombie
- From: Jim Correia <email@hidden>
- Date: Tue, 2 Aug 2005 21:52:52 -0400
Bill,
Thanks for the explanations. Followups inline.
On Aug 2, 2005, at 8:30 PM, Bill Bumgarner wrote:
On Aug 2, 2005, at 1:55 PM, Jim Correia wrote:
I have a CoreData based application. One of my NSManagedObject
subclasses observes itself (for a variety of reasons, but just
this in on the example) so it can keep a lastModified time for
each object.
Generally, observation of self is discouraged [though it should
work, I think].
Well it does, until I
a) remove the self-observer in dealloc, which causes faults to fire
and an exception to be raised as the object is deallocated (which is
understandable)
b) remove the observer is didTurnIntoFault which causes the problem
mentioned.
I guess since I'm observing self, there is no reason to remove the
observers as the object is going away.
In one other place, I am observing (in the example app)
resume.attributedString on self. This causes the same sorts of
problems. Is there a better way to handle this?
If I add an explicit observer, [resume addObserver: self ...] where/
when can I safely remove the observer?
In any case, you are going to end up with a boatload of observers
and lots of cycles spent maintaining the observers as managed
objects are created and destroyed.
In hindsight this is clear.
The motivation for this implementation was to be able to catch the
key changes in a generalized fashion rather than having to provide N
custom accessors each which did [self touch] at the end of their
implementation.
And there are some issues in relation to faults, as you have
discovered.
Instead, why not make the lastModifiedTime a dependent key on the
rest of the object's keys?
In particular:
- make lastModifiedTime dependent upon all keys that need to update
the lastModifiedTime
What happens when the dependent key is really a path?
In the example, resume might be large so at mmalc's advice it is a
separate entity so that the fault is only fired when the resume is
actually used, not when I load up the list of people for display in
the table view.
Is the only good solution here to do something similar on the Resume
object, but have it touch the object at the end of the owner
relationship?
- override willChangeValueForKey: to:
- call super first
- check to see if the key is lastModifiedTime
- if it is, then use primitive KVC to set the lastModifiedTime
to now
The above should work. At least, Ben and I think it will work.
Since this is more complicated than the second suggestion, I'll test
it out in the morning after sufficient caffeine and report back.
Alternatively, you could punt on the dependent key stuff and just
make willChangeValueForKey: always update the lastModifiedTime,
regardless of key (via the primitive KVC as described above).
Is the primitive KVC part important? If I do it via the primitive
values (and punt on the dependent key stuff) the changes don't show
up in the UI.
What I just hacked in, and it appears to work (but needs a closer
look and more testing) is
- (void)didChangeValueForKey:(NSString *)key
{
[super didChangeValueForKey: key];
if ([modificationDateDependentProperties containsObject: key])
{
NSUndoManager *undoManager = [[self managedObjectContext]
undoManager];
if (! ([undoManager isUndoing] || [undoManager isRedoing]))
{
[self touch];
}
}
}
and it appears to work. Is there any reason this approach is a bad idea?
Unfortunately, there isn't a "hey -- if that key changes,
independently recompute the value of this key" hook. There
probably should be. Someone should file a feature request, if they
agree.
It sounds like I agree, but I'll ponder some more before I go and
write a feature request.
Thanks,
Jim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden