Intermediate Fetching - Core Data - page 94

Note : The third concurrency type is .PrivateQueueConcurrencyType . You'll
learn about this type in Chapter 10, “Multiple Managed Object Contexts.”
Second, go to the venues property in ViewController.swift and change it to the
following:
var venues: [ Venue ]! = []
Since the original fetch request is asynchronous, it will finish after the table view
does its initial load. The table view will try to unwrap the venues property but since
there are no results yet, your app will crash.
You fix this issue by initializing venues to an empty array. This way, on first load, if
there are no results yet, your table view will simply be empty.
Let's see if your asynchronous fetch delivers as promised. If everything goes well,
you shouldn't notice any difference in the user interface. Build and run the sample
app. You'll see the usual list of venues as before:
Hooray! You've mastered asynchronous fetching. The filters and sorts will also work
as usual, except they still use a plain NSFetchRequest to reload the table view.
Batch updates: no fetching required
Sometimes, the only reason you fetch objects from Core Data is to mutate an
attribute. Then, after you make your changes, you have to commit the Core Data
objects back to the persistent store and call it a day. This is the normal process
you've been following all along.
But what if you want to update a hundred thousand records all at once? It would
take a lot of time and a lot of memory to fetch all of those objects just to update
one attribute. No amount of tweaking your fetch request would save your user from
having to stare at a spinner for a long, long time.