Error creating a separate NSManagedObjectContext

Question

Before getting into my issue, please have a look at this image.

Here is th

Answer 1

The old data that was in your persistent store, and addressed with the original MOC, is still there, and will be retrieved when the second MOC does a fetch. They're both looking at the same persistent store. It's just that the second MOC also has new data fetched from your API.

A synchronous network operation saving to Core Data will hang your app, and (for a large enough set of records) cause the system to kill your app, appearing to the user as a crash. Your client is wrong on that point, and needs to be educated.

Break apart your logic for fetching, saving, and viewing. Your view that shows a particular date's records should just do that--which it can do, if it accepts a date and uses a predicate.

Your 'cellForRowAtIndexPath' crash smells like a problem with a missing or misspelled identifier. What happens if you hard code a string instead of using 'record.name'?

Answer 2

Thread Safety

First of all I want to mention the Golden Rule of Core Data. NSManagedObject's are not thread safe, hence, "Thou shalt not cross the streams" (WWDC). What this means is that you should always access a Managed Object in its context and never pass it outside of its context. This is why your importer class worries me, you are inserting a bunch of objects into a context without guaranteeing that you are running the insert inside the Context.

One simple code change would fix this:

public func insertRecords(data: AnyObject, success: () -> Void, failure: (error: NSError?) -> Void) {
    let json = JSON(data)
    context.performBlock { () -> Void in
        //now we are thread safe :)
        if let records = json.array {
            for recordObj in records {
                let record = Record.MR_createInContext(context) as Record
                record.id = recordObj["Id"].int
                record.name = recordObj["Name"].string!
                record.date = NSDate(string: recordObj["Date"].string!)
            }
            context.MR_saveToPersistentStoreAndWait()
            success()
        }
    }
}

The only time you don't need to worry about this is when you are using the Main Queue Context and accessing objects on the main thread, like in tableview's etc.

Don't forget that MagicalRecord also has convenient save utilities that create context's ripe for saving :

MagicalRecord.saveWithBlock { (context) -> Void in
  //save me baby
}

Displaying Old Records

Now to your problem, the following paragraph in your post concerns me:

The user can tap on Past button to go to a separate view where he can choose a past or future date from a date picker view and view Records for that selected date. This means I have to call the API again passing the selected date, retrieve the data and save that data in core data and display them. When the user leaves this view, this data should be discarded.

I don't like the idea that you are discarding the information the user has requested once they leave that view. As a user I would expect to be able to navigate back to the old list and see the results I just queried without another unecessary network request. It might make more sense to maybe have a deletion utility that prunes your old objects on startup rather than while the user is accessing them.

Anyways, I cannot illustrate how important it is that you familiarize yourself with NSFetchedResultsController

This class is intended to efficiently manage the results returned from a Core Data fetch request.

You configure an instance of this class using a fetch request that specifies the entity, optionally a filter predicate, and an array containing at least one sort ordering. When you execute the fetch, the instance efficiently collects information about the results without the need to bring all the result objects into memory at the same time. As you access the results, objects are automatically faulted into memory in batches to match likely access patterns, and objects from previous accessed disposed of. This behavior further serves to keep memory requirements low, so even if you traverse a collection containing tens of thousands of objects, you should never have more than tens of them in memory at the same time.

Taken from Apple

It literally does everything for you and should be your go-to for any list that shows objects from Core Data.

When I fetch the objects from core data, I get that old data as well

Thats to be expected, you haven't specified anywhere that your fetch should include the reports in a certain date range. Here's a sample fetch:

let fetch = Record.MR_createFetchRequest()
let maxDateForThisController = NSDate()//get your date
fetch.predicate = NSPredicate(format: "date < %@", argumentArray: [maxDateForThisController])
fetch.fetchBatchSize = 10// or an arbitrary number
let dateSortDescriptor = NSSortDescriptor(key: "date", ascending: false)
let nameSortDescriptor = NSSortDescriptor(key: "name", ascending: true)

fetch.sortDescriptors = [dateSortDescriptor,nameSortDescriptor]//the order in which they are placed in the array matters

let controller = NSFetchedResultsController(fetchRequest: fetch,
        managedObjectContext: NSManagedObjectContext.MR_defaultContext(),
        sectionNameKeyPath: nil, cacheName: nil)

Importing Discardable Records

Finally, you say that you want to see old reports and use a separate context that won't save to the persistent store. Thats also simple, your importer takes a context so all you would need to do is make sure that your importer can support imports without saving to the persistent store. That way you can discard the context and the objects will go with it. So your method signature could look like this:

public func insertRecords(data: AnyObject, canSaveToPersistentStore: Bool = true,success: () -> Void, failure: (error: NSError?) -> Void) {

    /**
      Import some stuff
    */
    if canSaveToPersistentStore {
        context.MR_saveToPersistentStoreWithCompletion({ (complete, error) -> Void in
            if complete {
                success()
            } else {
                error
            }
        })
    } else {
        success()
    }
}