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 15:43:28 -0800
On Nov 18, 2008, at 13:53, John Clayton wrote:
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?
If you'll excuse a short rant ...
I think there's a semantic issue here, about what "deletion" means in
Core Data. AFAIK, it's not referring to the lifetime of the object in
your (in-memory) object graph, but the lifetime of the Core Data
entity instance in your persistent store. If I am correct, deleting an
object is "really" just an instruction to omit the object from the
persistent store the next time it's saved.
In those terms, it's not entirely surprising that the effect of
"deleteObject" might be deferred from the moment you call it to some
later time (processPendingChanges, or save, or whatever). The actual
object doesn't get deleted by "deleteObject", only its persistence in
the store. The object gets *deallocated* when there are no references
to it (regardless of whether it's deleted in the store or not).
I would have expected the delete rule to be applied at "deleteObject"
time, but it seems not completely illogical to do it later. (Part of
the reason for processPendingChanges is, I believe, to avoid tracking
a lot of redundant individual changes in the undo manager, and that's
a Good Thing.)
It might be worthwhile filing a bug on this, saying that the delete
rule ought to be applied at a predictable time, or that the
documentation should be updated to make it clear *when* it's done.
In practical terms, I'm suggesting you continue with your A/B
methodology:
[effect retain];
effect.layer = nil; // let Core Data do the work for the inverse
[moc deleteObject: effect];
[effect release];
I don't think this reeks of something broken, it just reflects a piece
of complexity in Core Data's semantics: there really are 2 things you
need to do -- one piece of object graph management and one piece of
persistent store management.
If it still crashes, then I would investigate the issue as a memory
management problem first.
_______________________________________________
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