Comments (2)
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.
from coredatastack.
@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.
from coredatastack.
Related Issues (20)
- Can't run app in simulator with BNRCoreDataStack in Objective-C project, LaunchServicesError HOT 1
- Build issues with Xcode 8 beta 3 HOT 4
- Creating CoreDataStack without dispatching HOT 2
- When using Mogenerator, making a ManagedObject implement CoreDataModelable gives error HOT 6
- NSPersistentStoreCoordinator options. HOT 5
- (Swift 3) Make `performAndWaitOrThrow` `rethrows` and `@noescape` HOT 1
- Issue compiling project with BNRCoreDataStack using Xcode 8 - Swift 2.3 HOT 1
- Publish Pod version 2.0.0 HOT 1
- performAndWaitOrThrow not accessible HOT 5
- Linker issue HOT 2
- Linker issue HOT 5
- Entity name check should not fail because of module name HOT 5
- BNRCOredatastack 1.3.0 issue in xcode 8.2 unable to install on device
- Question: is `.findFirstInContext(...)` not available any more on iOS < 10? HOT 3
- Support programatically created object models HOT 2
- Carthage validation script fails for forks
- Use withoutActuallyEscaping for helpers on Swift 3.1 HOT 5
- How can i use CoreDataStack in an Objective-C project HOT 1
- Xcode 9 support HOT 1
- crash on update of app from app store HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from coredatastack.