It's true that it would be rather awkward to extend an entity in a compiled managed object model, for exactly the reason you describe. As I see it you have a few options, in descending order of convenience:
- Include the uncompiled
.xcdatamodel
instead of the compiled.mom
. Anyone who has the compiled model can easily reverse-engineer it anyway, so it's not like this gives away any extra information. With the raw model, sub-entities can be created as usual. If you're concerned about compatibility of the existing entities, add in run-time checks to look overEmployee
and make sure it looks as you expect (for example, check the entity description'sversionHash
). If the original framework model is updated, changes should merge cleanly-- provided that you use the Xcode 4 and higher file format for the model. - Create sub-entities in code. There's nothing magic about the model editor, everything you do there can also be done in code. Create and/or modify entities when you first load the model by creating and/or modifying instances of
NSEntityDescription
and then callingsetEntities
on the managed object model. Just make sure you do so before loading a persistent store, because doing so after loading a store file will throw an exception. - (worst of all) Create a generic key-value store entity type in the model and give the
Employee
entity type a to-many relationship to it. Then you can add whatever key/value pairs you need at run time without needing to create a new sub-entity.
Core Data wasn't really designed with this kind of use in mind but that doesn't mean it isn't possible. I'd go with the first option myself, but the others will work too.