Core data: any way to fetch multiple entities?

Question

I'm just getting started with Core Data, and as a learning exercise I'm building an app where I need to display different types of objects in a single table view.

As an example, say I have an entity for "Cheese" and an unrelated entity for "Pirate". On the main screen of my app, the user should be able to create either a "Cheese" or a "Pirate" instance to add to the table view.

So, using the core data editor I've created entities for Cheese and Pirate... however, an NSFetchRequest seems to only allow you to retrieve one type of entity at a time with:

NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription entityForName:@"Cheese" inManagedObjectContext:_context];
[fetchRequest setEntity:entity];

Is there any way to perform a fetch that retrieves all "Cheese" and "Pirate" objects?

Thanks.

Solution 1

What you're trying to do is accomplished by defining entity inheritance in your model, where "DisplayableObject" would be an abstract class defined as the parent of "Cheese" and "Pirate".

Then you can perform a fetch request on the "DisplayableObject" entity and it will retrieve both entities' objects.

Take a look into this article in the apple documentation: https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/CoreData/KeyConcepts.html

Solution 2

I had to deal with this issue as well. Wanted to be able to search multiple entities but avoid inheritance that results in hierarchy of objects all stored in a single core data class and the performance issues that may result.

I opted for creating a concrete Searchable object that stores searchable terms common among the objects I want to search against. This object was added to each of the classes I wanted to search for:

Person.Searchable
Employee.Searchable
Department.Searchable

Searchable has fields such at searchTerm and to many relationships with each of the objects I need to search for. And a displayName so that the information can be shown to the user without having to query/load any other table.

Core Data queries are executed against Searchable so you only query a single entity.

Example:

Person { firstName = Joe, lastName = Jackson } -> searchable { term = joejackson, displayName = Joe Jackson, type = person }
Employee { firstName = Joe, lastName = Smith } -> searchable { term = joesmith, displayName = Joe Smith, type = employee }
Group { name = Joe’s Development Team } -> searchable { term = joesdevelopmentteam, displayName = Joe’s Development Team, type = group }

Now you can list and search for Person, Employee, Department all separate tables using their Searchable member using a single Fetched Request Controller.

Comments

[westsider]

But what if one wanted to use NSFetchResultController (not requested in OP)?

[Jim Rhoades]

I do want to use an NSFetchedResultsController, as that's what (I believe) lets me set the batch size for the request - so I'm not loading everything in memory at once. Also, I'll want to allow the user to manually reorder items in the table view, so I don't think appending two separate fetch requests into an array would work for that. I appreciate the answer though - and it's helped me clarify what I need to do.

[Rog]

You can also create two separate fetched results controllers for the same delegate.

[Huperniketes]

You're overcomplicating the code and degrading performance by using multiple fetches from multiple fetch controllers. For example, if there were nine or more entities your solution would be terrible to debug and modify. Defining an abstract parent entity which is referenced for fetches is both straightforward and easy.

[Corey Floyd]

Only problem with this solution is that if you setup all of your entities (or a majority of entities) to inherit from an abstract entity, Core Data's SQLite implementation handles this by place all instances of that entity in the same table. This severely degrades performance as the database grows.

[Swizzlr]

This is essentially a form of indexing isn't it?

[ArtOfWarfare]

Wait... I'm confused... what are the relationships involved here? Searchable has a to-many pointing at Persons, a to-many pointing at Employees, a to-many pointing at Groups, and none of those relationships have an inverse?

[Rizwan Ahmed]

This shouldn't be the accepted answer. This method is not efficient and it is not recommended.