views:

250

answers:

1

I am trying to create an application which allows background threads to update core data objects while the user might be reading the same data.

My approach to this would be to use multiple NSManagedObjectContexts and then before a background thread does a -save: operation, I fetch the object the user is currently working on and fire the fault for all its properties and relationships recursively. This way I have all objects the user could act with in my NSManagedObjectContext without seeing the already updated values.

But this can only work if the NSManagedObjectContext cannot decide himself that e.g. memory usage is too high, and starts faulting objects which I do not explicitly reference (other than through the NSManagedObject relationship).

So the question is, can the NSManagedObjectContext decide that an object needs to be re-faulted, without intervention from my side?

Thanks for your effort, Markus

+2  A: 

I believe there is nothing in the documentation for NSManagedObjectConext or NSPersistentStoreCoordinator that would prohibit the context converting an instance back into a fault if there are no unsaved updates to that instance.

Barry Wark
I agree with Barry, there is nothing prohibiting Core Data from re-faulting an object although I do not believe I have ever seen it on the desktop and I know that it DOES happen on Cocoa Touch.
Marcus S. Zarra
Hrmm, back to designing then... :-( Thanks for helping to both of you!
frenetisch applaudierend
Your use case is slightly unclear to me. Perhaps if you can describe the goal in a little more detail (including the actual use case), we could help suggest alternative architectures.
Barry Wark
Sorry for my late response. The problem I am trying to solve is updating the persistent store in the background while the user is still working with a previous version of the object graph. Specifically I want to avoid the user to see changes made by the update until he chooses explicitly to merge them.
frenetisch applaudierend
I believe your only option is to not save the background process' managed object context until the user chooses to merge the changes, then merge the changes into the UI managed object context. If you can't keep all of the data in memory and *have* to save the background context, I'm not sure there's a way you can prevent the changes from leaking into the foreground context under all circumstances, especially on the iPhone.
Barry Wark
Actually I have to save the changes, because I have to notify the background client if the save was successful or not. But I revisited my UI concept and the situation now only occurs while the user is in a modal dialog, editing a single object. There I have all objects the user sees directly referenced and it should not be a problem, or am I wrong?
frenetisch applaudierend