Core data Multi level parent - Child context

Question

In my app I have UITableViewController that shows event list. This controller uses ManagedObjectContext Say ParentContext. Now if any Event is selected, then a detailed View Controller is shown where users can edit the details of Event. So i have created a child context say,

ChildContext with type "NSPrivateQueueConcurrencyType"

ChildContext whose parent Context is "ParentContext".

My code is:

  NSManagedObjectContext *childContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
  childContext.parentContext = self.context ;

Now again there are some fields and relationships which needs another drill down. So i have created another ChildContext for the new view controller say,

GrandChildContext with type "NSPrivateQueueConcurrencyType"

GrandChildContext whose parent context is "ChildContext"

this process goes for another level ( Total 4 level from parent (tableView ) to child )

self.context - Parent Context
  |
  |
ChildContext
  |
  |
GrandChildContext
  |
  |
GrandGrandChildContext

---

My Entity Looks like this

EntityA           -- ( Edit View Controller  - uses ChildContext )
 |
 |- Field1
 |
 |- Field2
 |
 |- RelationShip (1 to Many ) - ( Relationship Add / Edit View Controller - uses GrandChildContext )
     |
     |- Field1
     |    .
     |    .
     |- Field3
     |
     |- Relationship ( 1 to Many ) - ( Relationship Add / Edit View Controller - uses GrandGrandChildContext )
            |
            |- Field1
            |
            |- Field2

Is this the right way of using Parent - Child context? Because at one point of time i will be having like 1 NSMainQueueConcurrencyType MOC and 3 NSPrivateQueueConcurrencyType MOC.

If it is not? is there any other way?

Does too many child context affects apps's performance?

Initially i used Properties and NSArrays to manage user entered data and when user hits done button, i will update / create managed objects. But this is a tedious job it made my view controller dirty. So i switched to Parent-Child context which is very easy to save / discard updates.

Thanks

Answer 1

You might have gone a little overboard with the multiple child contexts, but only a little, and your general approach is sound. A MOC (managed object context) is a fairly lightweight object.

I like your approach of having a distinct reference, within each view controller/scene, to the MOC that applies to that scene.

It is sometimes helpful to think about a MOC as a session or scratchpad. The matchup is not between MOCs and Entities, but rather between MOCs and logical units of work.

If one of your drill downs marks the beginning of some editing task that the user might want to abandon/cancel, that's a good moment to spin off a child MOC and pass it down to the new view. You can, if needed, rollback: or even just abandon the MOC, as you unwind back to the starting point.

On the other hand, if you were writing simply a viewer for static information, use just one MOC. In that case there is no need to or benefit from using more.

Answer 2

Perhaps there is a slight amount of confusion about the best use case for nested managed object contexts. For your case I would recommend to use only one single context.

Moving to Core Data from arrays etc. was a very good idea. Now unleash the true power and simplicity of the object graph. Try to keep things simple.

In order to drill down, just pass the context to the child view controller. Your child view controllers fetched results controller can use the same context as the parent view controller. Numerous Apple code examples use exactly this pattern.

The only time you need contexts is if you really need concurrency. This does not seem to be the case here at all. The new interface of the child view controller is shown once the data has been retrieved. If that takes too long (say, because the data comes from a web service) you show some kind of "please wait" interface and display the complete interface once the data retrieval is finished. Most likely this is not your scenario.