Core data: executeFetchRequest vs performFetch

Question

I want a thorough list regarding comparison between the two. Things I have known:

executeFetchRequest:

• Message sent to MOC
• Return an

Answer 1

About executeFetchRequest:

Message sent to MOC

Yes

Return an array of managed objects

Yes, but you can also change the type of results you want to retrieve. In NSFetchRequest you can set a different result type with:

- (void)setResultType:(NSFetchRequestResultType)type

where NSFetchRequestResultType can be of different types. Taken from Apple doc:

enum {
   NSManagedObjectResultType        = 0x00,
   NSManagedObjectIDResultType      = 0x01,
   NSDictionaryResultType           = 0x02
   NSCountResultType                = 0x04
};
typedef NSUInteger NSFetchRequestResultType; 

Goal: fetch objects from persistent store to MOC

Yes, creating a NSFetchRequest and performing a request, it the same as creating a SELECT statement in SQL. If you also use a NSPredicate it's the same as using SELECT-WHERE statement.

With table view: has nothing to do with table view

Yes, but with retrieved data you can populate a table

Frequency: often used in a loop, so could be called many many times

It depends, on what you want to achieve. It could be within a loop or not. Executing the request within a loop could have impact on performance but I would not be worried on that. Under the hood Core Data maintains a sort of cache mechanism. Every time you perform a request, if data are not in the cache, Core Data executes a round trip on your store (e.g. sql file) and populate the cache with the objects it has retrieved. If you perform the same query, the round trip will not performed again due to the cache mechanism. Anyway, you could avoid to execute a request within the run loop, simply moving that request outside the loop.

About performFetch:

Message sent to FRC

Yes

After calling it, use fetchedObjects to return an array of managed objects

Yes, but you can also retrieve an object with [_fetchedResultsController objectAtIndexPath:indexPath]; if you are populating a specific cell within a table.

Here I really suggest to read a nice tutorial on NSFetchedResultsController

With table view: FRC is specifically for keeping managed objects and table view rows in sync, and use performFetch to initialize that process.

Yes, a NSFetchedResultsController works in combination with a NSManagedObjectContext for you. Furthermore, it enables lazy loading of data. Suppose you have 1000 elements you retrieve and you want to display them in a UITableView. Setting a request for a NSFetchRequest like:

[fetchRequest setFetchBatchSize:20];

and using it with an instance of a NSFetchedResultsController, it allows to load 20 elements at first. Then when you scroll, other 20 elements are loaded, and so on. Without a NSFetchedResultsController you must implement this behavior manually. Refer to the tutorial I provided for further info.

Frequency: often only once. Unless fetch request of FRC changes, no need to call performFetch a second time

It depends on what you want to achieve. Most of the time you could call it once.

Hope that helps.

Edit

You have to call performFetch explicitly. I like to create a property for NSFetchedResultsController in my header file (.h) like

@property (nonatomic, strong, readonly) NSFetchedResultsController* fetchedResultsController;

and synthesize it in your implementation file (.m) like

@synthesize fetchedResultsController = _fetchedResultsController;

Then always within the .m file override the getter to create an new instance of it:

- (NSFetchedResultsController*)fetchedResultsController
{
    // it already exists, so return it
    if(_fetchedResultsController) return _fetchedResultsController;

    // else create it and return

    _fetchedResultsController = // alloc-init here with complete setup

   return _fetchedResultsController;
}

Once done, within your class (for example in viewDidLoad method) use it like

NSError *error = nil;
if (![[self fetchedResultsController] performFetch:&error]) {

    // Handle the error appropriately.
    NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
}