Core Data entity inheritance --> limitations?

Question

I thought I'll post this to the community. I am using coredata, and have two entities. Both entities have a hierarchical relationship. I am noticing quite a lot of duplicated functionality now, and am wondering if I should re-structure to have a base Entity which is abstract (HierarchicalObject), and make my entities inherit from them.

So the question is are there some limitations of this inheritance that I should take into account? Reading some of the posts out there, I see a few trade-offs, let me know if my assumptions are correct.

1. (Good) clean up structure, keep the HierarchicalObject functionality in one spot.
2. (Ok) With inheritance, both objects now end up in the same sqlite table (I am using Sqlite as the backend). So if the number of objects grow, search/sorting could take longer? Not sure if this is a huge deal, as the number of objects in my case should stay pretty static.
3. (not so good) With inheritance, the relationship could get more complicated? (http://www.cocoadev.com/index.pl?CoreDataInheritanceIssues)

Are there other things to take into account?

Thanks for your comments.

Hood

Answer 1

I think it's a mistake to draw to close a parallel between entities and classes. While very similar they do have some important differences.

The most important difference is that entities don't have code like a class would so when you have entities with duplicate attributes, your not adding a lot of extra coding and potential for introducing bugs.

A lot of people believe that class inheritance must parallel entity inheritance. It does not. As a long as a class descends from NSManagedObject and responds to the right key-value messages for the entity it represents, the class can have many merry adventures in it's inheritance that are not reflected in the entities inheritance. E.g. It's fairly common to create a custom base class right below NSManagedObject and the have all the subsequent managed object subclasses inherit from that regardless of their entities.

I think the only time that entity inheritance is absolutely required is when you need different entities to show up in the same relationship. E.g:

Owner{
  vehical<-->Vehical.owner
}

Vehical(abstract){
  owner<-->Owner.vehical
}

Motocycle:Vehical{ 

}

Car:Vehical{

}

Now the Owner.vehical can hold either a Motocycle object or a Car object. Note that the managed object class inheritance for Motocycle and Car don't have to be same. You could have something like Motocycle:TwoWheeled:NSManagedObject and Car:FourWheeled:NSManagedObject and everything would work fine.

In the end, entities are just instructions to context to tell it how the object graph fits together. As long as your entity arrangement makes that happen, you have a lot flexibility in the design details, quite a bit more than you would have in an analogous situation with classes.

Publius

Thanks for the detailed explanation! In my case, these are not really related entities, more for code "cleanup" and keeping the model sane. But given your comments, and Kendall's I am just going to leave it as it is. Not a huge amount of code, and dont' really want to deal with the potential down sides. Thanks again! – Hood

Answer 2

I thought it would be useful to mention that the Notes app on iOS 10 uses inheritance in its Core Data model. They use a base entity SyncingObject, that has 7 sub-entities including Note and Folder. And as you mentioned all of these are stored in the same SQLite table which has a whopping 106 columns, and since are shared among all entities most are NULL. They also implemented the folder-notes one-to-many relation as a many-to-many which creates a pivot table, which might be a work-around for an inheritance problem.

There are a couple of advantages to using entity inheritance that likely outweigh these storage limitations. For example, a unique constraint can be unique across entities. And a fetch request for a parent entity can return multiple child entities making UI that uses fetched results controller simpler, e.g. grouping by accounts or folders in a sidebar. Notes uses this to show an "All Notes" row above the Folder rows which is actually an Account child entity.

Showcase

Do you have a source on this? I would love to read more about it – Shalandashale

Sorry I don't, its just my own reverse engineering. I used momdec to decompile the model and Hopper to decompile the code. – Showcase

Answer 3

I have had issues in the past with data migration of models that had inheritance - you may want to experiment with that and see if you can get it to work.

As you noted also, all objects go in one table.

However, as Core Data is managing an object graph, it is really nice to keep the structure the way you would naturally have it just modeling objects - which includes inheritance. There's a lot to be said for keeping the model sane so that you have to do less work in maintaining code.

I have personally used a fairly complex CD model with inheritance in one of my own apps, and it has worked out OK (apart from as I said having issues with data migration, but that has been so flakey for me in general I do not rely on that working any longer).

Brunelleschi