CoreDataStack | The Big Nerd Ranch Core Data Stack

I worked out what was missing in my PreviewProvider struct:

1. I needed to perform a NSFetchrequest in order to get the data.
2. Then, I was able to access entries in the datastore using the array index.
   Note that the index is a CoreData internal representation, and if you want a specific item, use SQLite to browse the datastore to find the one you want to see.

Your context is defined in function parameters, thus it is not a CoreData context, but a TimelineProviderContext for the timeline.

Try fetch data with a following code as you do before adding a predicate:

Make this "context" global

I solved the issue:

It's not enough to just use a background context. You need to use that context on its own queue. You checked that you're not running on the main queue, but you could be on any queue, and the background context only works on one of them. The error message you see is what Core Data says when you're using it on the wrong queue.

Any time you use backgroundContext, you need to wrap the code in a call to perform or performAndWait, to ensure that your code runs on the background context's queue. Since your isExist function is synchronous, it needs to use performAndWait so that it can get a result before returning.

For one/few objects (that can be easily pulled into memory without issues), it is usually easier/recommended to -

1. fetch NSManagedObject into NSManagedObjectContext.
2. Perform your updates.
3. Save the context.

This saves you from having to merge the same set of changes to all other contexts in the app (which may have reference to the object being updated).

This works because NSManagedObjectContext fires notifications on save() calls that can be automatically observed by other contexts (if needed).

CoreData.framework doesn't open up SQLite level controls to the user, it provides you NSManagedObjectContext.

How does it work in a similar manner?

1. You pull as many objects in many as you need and do your changes on them.
2. When you are done with your changes, you do context.save().
3. In that way, you save all of your changes in one shot.

In all cases, pulling all objects in memory might not be possible or a good idea, so then you need to implement your own solution around how to send all of these changes to disk.

From the NSBatchUpdateRequest docs -

A request to Core Data to do a batch update of data in a persistent store without loading any data into memory.

When you execute this, you are doing the changes in store that you can't roll back. For a large data-set, you can do following -

1. Say you have to perform a series of updates (5 different steps) on 100k records as an operation.
2. Start in a background thread, pull objects in memory in batches of 1k at a time.
3. You can load 1k objects easily in memory, mutate them - go through all of your changes/steps one by one and save these changes on this batch. If this is successful, you move on to the next batch.
4. In case one intermediate step fails on a batch, you can then use either NSManagedObjectContext.rollback() or NSManagedObjectContext.reset() depending on your implementation.

Here's a popular SO post on the differences between the two in case official docs don't provide enough clarity.

Use CommandGroup, which has init options to append or replace existing menus:

I have been able to make it work!

My problem specifically was that I haven't updated my already fetched objects (with the old context) after reinitializing the persistenceContainer (which created a new context).

So, directly after calling setupContainer(), a simple fetch (with the new context) for all my objects was enough.