Richard, It's a fair question. The reason is that working with your data in separate contexts makes manipulating it safer. It can also make your model / controller code simpler and more structured.
At the "atomic level", core data maintains at most one instance of an managed object per context, in order to maintain consistency between objects in memory and in store. In other words, there isn't support for having "working-copies" of managed objects in the same context in the core-data framework. Typically a given application needs to both consume and change managed objects in memory, in different parts of the code. If all this is done in the same context, it falls on you to make sure that those operations are synchronised so that data and/or object-hierachy is consistent, can be reconciled with the store and is reflected in your views. In particular, managed objects and managed object contexts are not thread-safe, so you can't just put code which manipulates your managed objects on a dispatch-queue and expect it to Just Work. It may be feasible to implement all of this in one context for a given application, but will surely complicate your model and controller. If you separate tasks in different contexts, you can manipulate your managed objects, without affecting other contexts. From the perspective of individual contexts, all that is required is to that they can reconcile their managed objects with the store, though the store coordinator, for fetches and saves. Typically, changes in one context needs to be propagated to other contexts, but that is accomplished through the store coordinator by reconciling the objects in memory to the objects in store. That may be a trivial or nontrivial task depending on application, but it is well-supported in the framework. In general, separating manipulation into different contexts, makes it easier to compartmentalise tasks and controller / model code functionally. Mikkel On 31 May 2012, at 00:45, Richard Somers wrote: > I have a question about multiple contexts. > > First a quote from the Core Data Programming Guide - "To consider this from a > different perspective, a given object in a persistent store may be edited in > more than one context simultaneously. Each context, however, has its own > managed object that corresponds to the source object, and each managed object > may be edited independently. This can lead to inconsistencies during a > save-Core Data provides a number of ways to deal with this." > > So to recap, a given object in a persistent store may be edited in multiple > contexts simultaneously and each context has its own managed object > corresponding to the given source object. And when the user saves everything > is sorted out by Core Data. > > I know that Core Data is not multi-user but this sounds like a multi-user > data base use case scenario. Multiple contexts (users) all potentially > looking at the same data and the first one to save wins. > > Why did Apple do this? What would be a legitimate use case for this scenario? > > --Richard > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/my.inputstream%40googlemail.com > > This email sent to my.inputstr...@googlemail.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
