0

I'm working on a static library that will help sync Core Data iOS apps with a remote SQL database. My library relies on a few sync-related attributes that each Core Data entity must have, so I've created a parent entity, SyncObject, that all other entities inherit from. SyncObject is defined in the static library's data model and is included in the resource bundle (how's my terminology?)

When I create a new app that uses this library, I merge the the app's data model with the library's data model and programmatically set all of the app's entities as sub-entities of SyncObject. Remarkably, this all works, but it feels clunky: when auto-generating entity class files, I have to manually change the base class to SyncObject (which is itself a subclass of NSManagedObject) in the .h file, and I can't define relationships between entities in the app's data model and entities in the bundled data model because the Xcode data model editor doesn't know about the entities defined in the external bundle.

Is it possible to make the editor aware of bundled data models? If so, how?

Gregor
  • 585
  • 8
  • 19

1 Answers1

1

I would strongly recommend against this design. If all entities inherit from a single entity then your entire Core Data SQLite data structure will existing a single table. The performance cost for this is quite simply huge.

It is not possible to make the data modeler aware of the bundled data model.

Update

There is a difference between subclasses and sub-entities. There is nothing wrong with Subclassing. Creating sub-entities, however, is quite different and is designed to solve a different problem. Sub-entities are meant to intentionally combine so entities so that they share a common root and share a common set of properties or relationships. The cost of that is that they also share a common table. Which in the situation that they are intended for is not a significant cost.

The thread you referenced confused subclasses and sub-entities. They are not the same and they do not even need to align.

Trying to have an entire data model be sub-entities of a single parent entity is not the intended use of that feature of Core Data. It will cause horrific performance penalties and eventually stop your application from working. You would be better off working from a different design. For example, you could force them to subclass from your class which then subclasses NSManagedObject and do what you need to do in that subclass. You could further require an attribute to exist in each entity so that you can complete your goal.

mogenerator works in that vein (although it does not require an attribute to exist in the entities). There are also syncing frameworks that work off a similar design. They require that each entity have a unique identifier key, etc.

You could go even further and not necessarily require an attribute but instead require that the subclasses define a unique identifier so that you framework can uniquely identify each instance of an entity. You could then work with that uniqueID without requiring its definition be specific (a string, a number, etc.).

Marcus S. Zarra
  • 46,571
  • 9
  • 101
  • 182
  • Thanks for your response. When you say you recommend against the design, is it actually a bad design (adding sync metadata to each object by inheritance) or is this simply a limitation of the Core Data framework? Can you recommend anything? This thread proposes a work around, but it also seems pretty clunky: http://stackoverflow.com/questions/6917494/core-data-performance-with-single-parent-entity – Gregor Jan 28 '14 at 18:12
  • An easy way to see what Marcus is saying is open the resulting database and look at the table being generated. I would expect to see wide table with a bunch of optional columns as opposed to what you are trying to model which is a bunch of tables with a similar set of columns. I can point you at AFIncrementalStore and RestKit which rather than make everything a sub-entity of some root entity they programmatically modify the model at run time to add the columns they need to each entity. https://github.com/AFNetworking/AFIncrementalStore/blob/master/AFIncrementalStore/AFIncrementalStore.m#L677 – Anthony Jan 28 '14 at 23:02