toggle quoted messageShow quoted text
Thanks, that’s good to know for the easy path. What about the case where I want to update the model to reflect the class hierarchy? Based on what the Common superclass will handle, I can see that it would be more convenient to request instances of Common to perform certain operations rather than iterating over all the subclasses.
PS: Regarding SuperClock!, I hope you’re not waiting on any updates. ;)
On Sep 22, 2018, at 11:45 AM, Chris Hanson <cmhanson@...
On Sep 21, 2018, at 9:26 PM, Steve Christensen via Groups.Io <punster@...
Is this possible using just a new model version and/or mapping model, or does it require something more involved?
In fact you don’t even need a new model version, you can just refactor the code.
We made sure that Core Data’s concept of entity inheritance is independent of class hierarchy, so you don’t actually need to create a parent entity that corresponds to the Common class if you don’t want to be able to have a query return instances of both Entity1 and Entity2.
This only works if you’re not using code generation. Xcode’s Core Data code generation (whether invoked automatically or manually) does assume entity and class hierarchies are the same, and will only use NSManagedObject as a parent class for base entities, not some other class you specify. This is one reason we allow category/extension-only code generation: It lets you maintain the class hierarchy you want, while still letting Xcode generate the accessor declarations.
PS - I’m still using SuperClock on my vintage Macs. :)