Re: CoreData retain/release/delete
Re: CoreData retain/release/delete
- Subject: Re: CoreData retain/release/delete
- From: Bill Bumgarner <email@hidden>
- Date: Fri, 29 Apr 2005 14:46:12 -0700
On Apr 29, 2005, at 1:22 PM, John Brownlow wrote:
- (void) dealloc
{
// regular dealloc stuff
[[self managedObjectContext] deleteObject: self];
}
It seems like it would work and is reasonably elegant, but it seems
a bit too obvious to be valid code! :)
The above would imply that you want to permanently delete the managed
object from the store when the last reference to the object is released.
That seems like an odd design in that it is mixing business logic
with generic object life cycle management.
If the managed object context is set to not retain registered objects
-- which is the default -- then the deleted managed object should be
reaped once all retains are cleared. If it has been deleted and not
saved, it will be reaped once the save occurs.
As Scott said, you really don't want to mess with Core Data's object
life cycle management in the name of trying to manage your object graph.
It sounds like you probably want to set up an appropriate delete
rule. Most likely, you'll want to set the relationship to the
object to use a cascading delete such that when the "owning" object
is deleted, the destination object is also deleted.
More importantly, what happens to the copy in the persistent store?
When the MOC saves, is the persistent store overwritten, and the
object effectively deleted from the saved file, or does it hang
around and have to be deleted manually using the -deleteObject method?
If you delete an object, it will be deleted from the store upon
save. Whether the store is overwritten is dependent upon what store
you choose. XML and Binary will atomically overwrite the store. SQL
will simply update the necessary rows in the store, deleting rows
representing deleted object methods.
If you still have references to the deleted object and you save, the
object will not be dealloc'd out from under you. Instead, it will
be turned into a fault that cannot be fired. An attempt to fire it
will cause an exception to be tossed.
b.bum
_______________________________________________
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