Re: CoreData transient attribute memory leak?
Re: CoreData transient attribute memory leak?
- Subject: Re: CoreData transient attribute memory leak?
- From: Jakob Olesen <email@hidden>
- Date: Fri, 8 Sep 2006 11:22:15 +0200
On 07/09/2006, at 22.34, Drew McCormack wrote:
Actually, I only have one context, but I have fetched properties,
and to refresh them I need this method. I need to use YES, because
I don't want to lose changes in the object that are not yet in the
store.
It seems to me that a single awakeFromFetch method is not entirely
adequate, because there are different types of fetches. When the
object is first fetched from the store, you need awakeFromFetch to
set transients. But when a refresh occurs, you don't want to set
transients. Two quite different circumstances. Seems to me that an
awakeFromRefresh may not be a bad idea.
The utility of -[awakeFromFetch] for setting transients is a little
foggy, yes. It would be nice to have callbacks before the object is
turned into a fault and after the transients are restored, both with
change management disabled, like -[awakeFromFetch]. That would give
you much better control of how transients behave across a refresh.
Note that if you set a transient property to nil or -[NSNull null]
before calling -[refreshObject:mergeChanges:YES], then the value you
set in -[awakeFromFetch] will be preserved. That is a bug in either
the documentation or the implementation, I don't know which.
I sometimes use an NSManagedObject category and an
NSManagedObjectContext subclass:
@implementation ExtendedManagedObjectContext
- (id)refreshToken;
{
return refreshToken;
}
- (void)setRefreshToken:(id)token;
{
[token retain];
[refreshToken release];
refreshToken = token;
}
- (void)refreshObject:(NSManagedObject *)object mergeChanges:(BOOL)flag
{
[self setRefreshToken:nil];
if (flag && ![object isFault]) {
[object willRefreshAndMergeChanges];
[super refreshObject:object mergeChanges:flag];
[object didRefreshAndMergeChanges];
}
else {
[super refreshObject:object mergeChanges:flag];
}
[self setRefreshToken:nil];
}
@end
This gives you callbacks before and after the event. I use the
'refreshToken' to store state that the object wishes to keep after -
[didTurnIntoFault:]
However, these methods are called with change management enabled,
unlike -[awakeFromFetch], so they are not that useful.
In your case, you can get the same behaviour as -[awakeFromRefresh],
though:
- (void)willRefreshAndMergeChanges
{
[[self managedObjectContext] setRefreshToken:@"merging"];
}
-(void)awakeFromFetch
{
...
if([[self managedObjectContext] refreshToken]==nil) {
// not merging, set transients
}
...
}
(You need a cast in there to avoid compiler warnings about the new
messages, I left them out for readability)
It is really cool that Cocoa lets you make fixes like that.
_______________________________________________
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