CODEWITHSUNDEEP
iosobjective-ccore-datadatabase-performance
InvalidReferenceException
InvalidReferenceException

Reputation: 949

Core Data - accessing instances in a to many relationship vs fetch request?

I have a Core Data model in my app with a 'Notebook' entity. There are two ways I could access one or many 'Notebook' instances:

It is much easier to query an 'AppData' instance for 'Notebook' instances and their attributes than setting up a fetch request to the managed object context each time.

However, which method would be faster? would one method use more memory or stay in memory more time? I read that objects in to-many relationships are loaded lazily, but when would an object in that set be loaded? when would it be unloaded?

Upvotes: 0

Views: 332

Answers (1)

Mundi
Mundi

Reputation: 80265

The AppData entity seems redundant. You have to fetch it first, so why not fetch all Notebook instances instead? The filtering (by title, other ID attributes) would be the same in both scenarios.

A fetch request does not have to be painful: 

NSFetchRequest *fetch = [NSFetchRequest fetchRequestWithEntityName:@"Notebook"];
NSArray *fetchedObjects = [moc executeFetchRequest:fetch error:nil];

Also, depending on the amount of data you can filter these in-memory, or include a predicate in the fetch request.

Definitely, regardless of the scenario, forgo your idea of the "index attribute". Core Data is an object graph, not a database. The only justification for this could be if you need to sync with some external framework or data store that uses unique identifiers.

For convenience, you could create a method in a category of your managed object.

+(NSArray*) appNotebooks {
   NSArray * fetchedResults = // fetch the appropriate entities
   return fetchedResults;
}

Then you would use it like this: 

Notebook.appNotebooks;

Upvotes: 2

Related Questions