Re: core-data crash on save.
Re: core-data crash on save.
- Subject: Re: core-data crash on save.
- From: Quincey Morris <email@hidden>
- Date: Tue, 18 Nov 2008 10:06:32 -0800
On Nov 18, 2008, at 00:27, John Clayton wrote:
In my program I have a check-box that switches a particular effect
on/off, an opacity fade in this case. Switching the effect off will
delete the effect from the core-data graph in the following manner:
A - remove the effect object from the list of effects on the layer
(using core-data generated set accessor method)
B - delete the effect instance (using the managed object context
deleteObject: method)
switching it on (via the checkbox) adds a new Effect instance back
into the graph. My requirements are, among other things:
1 - when a layer effect is deleted, reflect the change immediately
in the UI
2 - don't orphan data objects in the DB
requirement #1 here is the interesting one. If I DO NOT perform
Step A, then I fail requirement #1, because step (B), while working
- is 'lazy' in the sense that I'll only see the delete at save
time. if I DO NOT perform step B, then I end up orphaning the
effect object (fail on #2), but I do fullfil requirement #1. I'd
like to have both - however, if I perform both Step A and Step B, I
crash on save (with what appears to be a double delete - i.e. msg
send to a dead object) :
You're not including some key information in this description. You
have a to-many relationship Layer->Effect. Is there an inverse
relationship Effect->Layer? If so, what is its delete rule?
If you have an inverse relationship, and the Effect->Layer delete rule
is Nullify, then it's not necessary to do part A -- it happens
automatically, and #1 happens as result, assuming that the UI is
properly watching for KVO notifications for the Layer's "effects"
property.
I suspect, though, that you actually have a memory management problem.
If you do A first, then it could well be that the Effect object is
immediately deallocated, unless you retain it before removing it from
the relationship. (It was retained before the removal because it was
in the NSSet representing the relationship, but possibly nowhere else.
Managed object contexts don't routinely retain their objects unless
you tell them to.) If you then do B next, you no longer have a valid
object to pass to deleteObject.
This might not be precisely what's happening, and of course it won't
happen like this if you're using garbage collection, but memory
management deserves some investigation, I think.
_______________________________________________
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