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

Estonian

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.

Spectral

In all the drill downs i have editing task. I have just managed to cut few save / cancel operation in some of drill down. After working with this model for some time, the only problem i found is that, the relationship created are not visible in the parent child. This happens only in ios 5, this is a known bug and i fixed it by calling obtainPermanentIDs just before saving child contexts – Estonian

Oh my god, +krishnan, I tore my hair half out before I found this comment and tried adding an obtainPermanentIDs call. – Marybellemarybeth

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.

Rubstone

If you look at link wwdc 2012 video core data best practices session 214, it shows how to use parent and child context to show detail view controller. I am using the same technique, so that if user hits save button i could save the child context and all the changes of child context will be pushed to the parent context. And when user hits the cancel button, i simply dismiss the view controller and all the changes will be lost. Here All my child view controllers are detail inspector where use edits data, so no fetched results controller. – Estonian

You can achieve the same with just one context using [context rollback]; instead of [context save:nil]; . The WWDC video is useful if the fetch for the detail view controller would take an inordinate amount of time. – Rubstone

i think you din't understand my question. My questions is similar to this one. But in my case i have multi level child context. With [context rollback] all my changes will be lost. But instead i want only some changes to be discarded. I will upload a sample project soon. thanks – Estonian

@Rubstone "You have a completely wrong idea about contexts. You need exactly one context. Period." Wait. WHAT?! No no no. A context is a set of changes. It's not persisted until you commit it. You can, and should, have as many as you have change sets for. That should be pretty clear from the first two paragraphs in the NSManagedObjectContext documentation: developer.apple.com/library/ios/documentation/Cocoa/Reference/… – Atmosphere

In his use case it is exactly what he needs. This answer is tailored to the skill and experience level of the OP. – Rubstone