Re: core-data crash on save.
Re: core-data crash on save.
- Subject: Re: core-data crash on save.
- From: John Clayton <email@hidden>
- Date: Tue, 18 Nov 2008 22:53:20 +0100
Hi there, comments embedded below...
On 18/11/2008, at 7:06 PM, Quincey Morris wrote:
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.
The delete rule is Nullify. You are right of course, there should be
no need to perform Step A if the rules are working OK. But that's
exactly what I'm saying - when I delete the object, nothing actually
happens on the KVO notifications, zero. That is, until I call
processPendingChanges on the context.
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.
So, with the extra two bits of knowledge, namely:
- I have a Nullify relationship from Effect to the Layers 'effects'
set/relationship
- it works if I call processPendingChanges
does it still 'reek' to you of something being broken?
I'm a bit lost as to why I must call processPendingChanges to have my
object deleted immediately. It really does feel like I've screwed
*something*, *somewhere*. I thought the objects that I delete would
really be deleted at the end of the event loop?
_______________________________________________
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