Kodeco Forums

Core Data Tutorial: Multiple Managed Object Contexts

Learn how to use multiple managed object contexts to improve the performance of your apps in this Core Data Tutorial in Swift!

This is a companion discussion topic for the original entry at http://www.raywenderlich.com/113489/core-data-tutorial-multiple-managed-object-contexts

Hello Mr. Morey: I find this article fantastic. But I have some issues with the SQlite. I cannot (or don’t know how to create) the other files wal and shm. My app creates the DB .sqlite in each device when it is firstly open. But it is not creating the other 2 files. I approach to your kind help, to ask you if you can explain how to get this solved?

@fgodinez the wal and shm files will be created for you automatically by Core Data. You’re using Core Data and not SQLite directly, correct? I would try loading up CoreData with some dummy data programmatically and then saving the context. Do you now see the wal and shm files?

i have some problem with multiple context its going wait trap deadlock when execute fetchrequest and after save the context both are showing in wait trap what problem i am not able to fig out can you help me

I’m not sure. I haven’t see that issue before. I would recommend using Instruments to see what is going on.

this problem is coming in ios9 and xcode 7 is there any things changed in core data consistency label .let me know any things to you know it . i will try in Instruments let see…thanks

@mmorey Thanks for this great tutorial. I have a question though, you have used

childContext.persistentStoreCoordinator = coreDataStack.context.persistentStoreCoordinator

Why not “childContext.parentContext = coreDataStack.context” instead?

I need more context to answer you question. What file and line are you referring to in the final project?

I’m talking about page 250,

let privateContext = NSManagedObjectContext( concurrencyType: .PrivateQueueConcurrencyType)
privateContext.persistentStoreCoordinator = coreDataStack.context.persistentStoreCoordinator

versus page 253, where it talks about using childContexts instead. You use childContext in

let childContext = NSManagedObjectContext( concurrencyType: .MainQueueConcurrencyType)
childContext.parentContext = coreDataStack.context

What I’d like to know is what’s the difference between the two? Where should you point private context’s persistentStoreCoordinators to the main’s persistentStoreCoordinator and where should you set child context’s parentContext to the main context?

For the sample app the child context is being used like a scratch pad, if you hit the cancel button you can just throw away the whole context.

A private context can be used to import data without blocking the UI or main queue.

in func exportCSVFile() can you explain the code on comment # 4
if let fileHandle = fileHandle {

What is being done here. can you explain in detail?

This function handles the exporting of the data to a plain text CSV file. To export to a file, first a file handle is created. File handles in iOS are just a way to manage the dealings with a file.

I would like to seed the app core data from Sqlite DB (since the same db can be used to seed an Android app) how would I set the relationships between the tables? The very first time, code can import sqlite db into a file inside app documents directory, and then the relationships can be set between tables inside core data and work with core data. Next time, if the app wanted to update the sqlite db a new version with a new table and if that new table has relationships to one of existing tables that was already imported in core data iwhen the app was set up first time then it would not be possible to set the new relationships in core data since the app is already loaded right? In that case how should I handle it?

@mmorey Is it possible that we can have only one context i.e Private context and we can do all fetch and save in background only, which will not even block the UI?

In the case you are describe you would have to manually perform the migration. Meaning you would have to write custom migration code to handle it.

Yes, it is possible.