Managed Objects and Contexts

  • 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
  • Hi Richard-

    The reasons to have multiple contexts within an app are as varied as application architectures, and do not need to correspond to multiple users (I'd go so far as to say "shouldn't", but I'm sure someone could find a way to make it work).  An app I once wrote maintained two contexts that looked at the same data.  The first context was essentially user-facing: actions taken in the UI resulted in changes in the context.  The second context was something of a read-only snapshot of the first that was then used on a background thread to do work (the app allowed the user to visually create a workflow to do this work).

    In more modern Core Data usage, it is good practice to maintain two contexts: a parent and a child context will allow for background saving in the new document architecture "for free".

    In short, there are possible scenarios for using multiple contexts that are views on the same data, but the one you mention (a context for each user independently manipulating the same data) is probably not one of them.

    Hope this helps!

    John

    On May 30, 2012, at 4:45 PM, 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
  • 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
  • John and Mikkel,

    Thanks for the insight on multiple contexts in Core Data. It helps a bunch.

    --Richard
previous month may 2012 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today