views:

17

answers:

1

The documentation for the -reset method of NSManagedObjectContext is confusing...

All the receiver's managed objects are “forgotten.” If you use this method, you should ensure that you also discard references to any managed objects fetched using the receiver, since they will be invalid afterwards.

So what does that mean? When I have fetched any objects from the persistent store, and then reset my context, how would I "discard references"? Why must I do that?

+1  A: 

If you get a NSManagedObject from the store somewhere in your code, then somewhere else you reset the the context, now you change the ManagedObject and try to persist it to the store through the context (which is reset and has no references to any objects) it will crash your app.

The context is a "scratch pad", it has "access" to all the stuff in the store, but it only deals with/has drawn in, Objects that you retrieved through it after the app launched. When you read in an NSManagedObject, the context (as far as I know) makes a copy and track all changes you make to it, it does nothing to the store before you persist it. This is what makes for the memory management in core data and the easy implementation of undo-redo etc.

So resetting the context also throws away these changes and there is nothing to persist to the store.

EDIT://added

The reference you should no pay to much attention to. You don't have to release it or the like, Core Data will take care of that, just don't reference the ManagedObject and the autorelease pool will discard of it.

RickiG
Not sure if I can follow: When I create a managed object for a specific context, and then reset the context before saving, I can crash the app by calling -save after -reset? Isn't that a bug in Core Data? That shouldn't happen. -reset should throw this away, and -save should know there is nothing. Or did I get that wrong?
dontWatchMyProfile
Hi no I don't think that will crash the app, the context has the hasChanged property that I think Core Data checks before doing anything. So a "clean" context will not be persistet. The crash part is if you reference the ManagedObject after the reset, change it or get caught by the autorelease pool having deallocated it.______________I sort of get the feeling you are trying to do something like using the managedObject for temporary storage and then just discard the context to get rid of the ones you don't need? That is usually a bad idea:( (I'm just guessing of course.. sorry if it's wrong)
RickiG
haha no i'm not trying that. All I try is to completely understand core data. That's why I'm interested in every single method.
dontWatchMyProfile
I tried this: I used the default core data template for an view based iPhone app. In the insertNewObject method I created called -reset at the end. No crash. But as soon as I inserted another new object, the whole app crashed immediately on the line where the -save is called, telling that some managed object is deallocated. Now I'm not sure if that's because NSFetchedResultsController is referencing all the objects somehow.
dontWatchMyProfile
Not sure I understand what you are doing. The memory management in Core Data is merciless, that is why it can handle large numbers of objects even with the limited memory of the iPhone.It is an API where it really stings you for not following best practice. So try to limit passing your managed objects around your app to a minimum. It is usually better to get the object, use it and if you change something, persist it, else just forget about it.Have you read the Guide? it is hours of "fun" :http://developer.apple.com/mac/library/documentation/cocoa/conceptual/CoreData/cdProgrammingGuide.html
RickiG
Agreed. Yes, I'm currently reading it, and in parallel I start to follow what they say and try it all out. Most of unclear things end up here on SO. See my other questions. Plenty of them.
dontWatchMyProfile