How many of the parent context gotchas from this article still apply?

[jeremy-w]

Article: http://benedictcohen.co.uk/blog/archives/308

Mentioned:

• Weirdness about temporary vs permanent object IDs
• -awakeFromInsert breaking doc contract and being called multiple times as changes propagate upwards
• Caching up the parent context tree that can cause child contexts to fetch outdated values
• Merge policy ignored during upward propagation

I'm specifically curious about contrasting the recommendation to have main queue -> PSC with private queue worker contexts hooked up to main queue context only as needed, vs the main -> private -> PSC stack recommended in this repo. What are the dis/advantages and tradeoffs between the two?

[rcedwards]

This is a great post @jeremy-w thanks for linking me to it. I do think this post points out some of the gotchas associated with nested contexts, however I still think in most cases a nested MOC structure is preferable.

Caching issues:

I don't believe this poses a problem in our stack. The root context should never be modifying objects directly. This context would be a private property of the stack had it not been for the issues with iOS 8 CD feature (batch updating/async fetching). If something was modified on the main queue context and then never saved the children would see that change which may be an issue. However I would always recommend that temporary changes be on a context other than the main context and any changes on the main context should be saved immediately.

Temp ID vs Permanent ID:

This is certainly a tricky drawback of the nested context structure. That being said using managed object IDs to access objects between context is far less common when using a nested MOC stack since common ancestors or members of the same hierarchy have access to the same objects and changes.

In "avoid passing temporary objectIDs between contexts" recommendation the method obtainPermenantIDForObjects:error: is recommended to be used. This might be helpful in these cases where you must pass object IDs between contexts.

Awake From Insert:

This may be a bit misleading in the discussion section of the documentation, however the description of this method does indicate it will be called upon insertion into a managed object context. So yes this will be called for each context the object is pushed up into. I will add this to my notes on the SMS repo where this method is explained.

Merge Policy:

Of all the issues I think this is the most glaring. Merge policies do state they are for

resolve[ing] conflicts between the persistent store and in-memory versions of managed objects.

So it seems that there just isn't a way to set a preference with child context pushing changes into the parent. Also something that should be documented in the repo README. Fortunately if we're saving our main queue context synchronously after making changes, we wouldn't see changes being wiped out from child context.

Reason for Main -> Private -> PSC recommendation:

With this setup we benefit from saves to the store occurring on a background queue rather than the main thread. This is a big performance boost as writing to disk is the most expensive operation. Basically number 3 in his advice.

General Recommendation Pros/Cons:

I think this post does a good job with recommendations that we too should include with our stack.

I believe that number 3: "To delay modifying the persistent store" is important enough that a nested stack is logical from the beginning. I also believe that the simplicity of nested contexts outweigh the issues therefore saying that "Children of a mainQueue context should only be other mainQueue contexts" is an overstatement to me.

I agree with many of the other points though. For most operations in your application you should be perfectly fine using the main queue context until you either hit a log running task (number 1) or have changes that should be discarded (number 2). I also think the idea of discarding child contexts after they have been saved is a great recommendation also. Less risk of dealing with stale data or stomping on other contexts.

[rcedwards]

@jgallagher, @lyricsboy, @randomstep

I wanted to also solicit your thoughts on using a nested managed object stack vs a shared PSC stack. My thoughts are if we are going to make a general all purpose stack as our CoreData starting point, it may be beneficial to only have a single recommended stack and reserve the shared PSC stack (or other configurations) for specialized cases.

@jgallagher I know you referenced Florian Kugler's post on the performance when doing large imports http://floriankugler.com/2013/04/29/concurrent-core-data-stack-performance-shootout/ however I'm not so convinced this is still the case. I need to run some benchmarks on a device but this is what I've found from the simulator so far:

Inserting over 10,000 records:

Shared PSC without Nesting:

Here is the same for Nested MOC stack:

While the nested MOC stack takes about 280 ms longer overall it spends about 70 ms less time on the main thread. Long story short, it seems like these numbers are at the very least far different than what Florian observed in his post.

Apple actually recommends if you're hitting performance issues from the store locks, to set up two stacks with their own PSC and only share the store file.