views:

154

answers:

1

Hi folks,

I'm working on a Core Data iPhone app that pulls remote resources from the web into NSManagedObjects and saves them locally.

I want the user to be able to designate which of these objects should be saved. This means that some will be saved, but many should be deleted. However, I might want to save and delete at different times - I'd prefer to save designated objects immediately (in case the app crashes), but still keep around the other objects because they're hanging out in table views and such.

One approach I can think of is to have a different persistent store - one for stuff that will be saved, one for stuff that won't; this way I can save the "should be saved" store at any time. However, I would much prefer to keep objects of the same type in the same domain.

Another approach would be to just save at the very end - negating any ability to recover from a crash. But saving at the end would allow me to parse out any objects that weren't designated "should save".

And that's really what I want - a "shouldSave" method in the NSManagedObject class, or at least a save method that I could fire at select objects. But as far as I can tell, neither of those exist.

So, if anyone has any other suggestions, please let me know! It would be greatly appreciated.

A: 

CoreData is not for object serialization, it is an object graph serialization. That is an important distinction. Once you have an NSManagedObject it is associated with a context, and CoreData handles saves at context level since that is the only way it guarantee any sort of object graph consistency. In other words, you can't save individual objects because if they have relationships with other objects you would need to also save those objects and it quickly cascades out to the whole graph.

You seem to be worried about crash recovery. If the app crashed and the user relaunched it would they expect to see just the items they saved, or everything that was on the screen before they crashed? If it is the former you should just delete them at save time and remove them from the users view (with some animation), if it is the later you should commit out everything, and potentially delete the objects you are not interested in at another time.

Louis Gerbarg
I think my Rails background just wants core data to be a "smart graph" that can cascade the saving of related objects without having to save everything else :)That not being the case, I've thought about your questions of crash recovery, which were very helpful. I think my best bet is to save everything once downloaded and merely do deletes later - such as when the user does a new search, effectively clearing out any objects from the last search, as well as a general clean at startup time.Thank you very much for your input!
Mike Laurence