Inheritance Core Data: Do I need to specify a Subclass in my xcdatamodel? - objective-c

Question

I have a base class called Mail that will essentially act as an abstract class which will have concrete subclasses that determine things like the mail's subject, body, sender etc.
Let's call one such concrete subclass NewsMail.
I've set up polymorphic relationships in Obj C before but never in CoreData.
It seems as though the following line is expecting a class thats declared in the xcdatamodel. The following line:
[NewsMail MR_createInContext:[NSManagedObjectContext MR_context]];
produces this error:
"NSInternalInconsistencyException", "+entityForName: could not locate an entity named 'NewsMail' in this model.
Now I could get around this by adding an entity in my xcdatamodel for every concrete subclass I have but this will grow unwieldy after a time.
Advice?
UPDATE
So I have a category 'Mail+Types' where I intend to configure the concrete types:
#import "Mail.h"
#import "MailProtocol.h"
#interface Mail (Types)
+ (instancetype)newInstanceInContext:(NSManagedObjectContext*)context;
#end
#interface WelcomeMail : Mail<MailProtocol> #end
MailProtocol will define the additional methods that a concrete Mail should conform to:
#import <Foundation/Foundation.h>
#protocol MailProtocol <NSObject>
- (NSString*)subjectKey;
- (NSString*)bodyKey;
- (void)build;
#end
The (instancetype)newInstanceInContext:(NSManagedObjectContext*)context; method should return a concrete class but built from the parent Mail class, as pointed out in an answer below:
+ (instancetype)newInstanceInContext:(NSManagedObjectContext*)context
{
return [NSEntityDescription insertNewObjectForEntityForName:#"Mail" inManagedObjectContext:context];
}
I can confirm that the correct concrete class implementation of newInstanceInContext is executed.
Unfortunately, if I try to run build on a WelcomeMail I get an 'unrecognized selector' error because it tries to run it on the Parent 'Mail' class.

Answer 1

You can do it but I suspect not the way you want to. I don't use MR but it seems obvious it has a factory method to create your managed object based on the class name - and because you don't have an Entity with that name it fails.
What I have done is created both Entities in the MOM editor and marked, for example Mail, as abstract then added each subclass as entities which are derived from Mail. Not sure what you want to do with each derived class where this is that much of a burden. After all, each derived class only then needs the additional attributes that class needs which they don't inherit from Mail. Including for example transient attributes which can be used to add business logic by adding behavior that's not part of the stored model.
The other thing I often do which does work is inherit from the managed object in code - model not stored in the MOM - to add additional logic. But in that case I usually add a factory method myself to instantiate the actual MOM Entity. I suspect in this case MR may be trying to help you by creating a MO with the wrong Entity.
Just to elaborate a bit. I usually create a 'base' model object that's not stored in Core Data that looks like:
#interface BaseModel : NSManagedObject
+ (instancetype)newInstanceInContext:(NSManagedObjectContext*)context;
#end
#implementation BaseModel
+ (instancetype)newInstanceInContext:(NSManagedObjectContext*)context
{
return [NSEntityDescription insertNewObjectForEntityForName:NSStringFromClass([self class]) inManagedObjectContext:context];
}
#end
My actual model object, say Mail (which is defined in the MOM), inherits BaseModel.
I then further derive another class from Mail. Say ExpressMail. ExpressMail inherits Mail. But overrides newInstanceInContext with:
+ (instancetype)newInstanceInContext:(NSManagedObjectContext*)context
{
return [NSEntityDescription insertNewObjectForEntityForName:#"Mail" inManagedObjectContext:context];
}
Basically it creates a Mail MO. I can then add additional logic to ExpressMail. With the obvious understanding that I can't add any properties here that will be persisted outside of what's in Mail.
Not sure if this is what you want but its a pattern I use frequently to do something like what you are trying to do.
UPDATE
Updating after several comment threads. I think we both realized down casting is not going to work. If you really only want to add behavior - i.e. add methods that can decorate or work on your base class - Mail - then categories should definitely work. If you really only need your POMO (plain old mail object) then you can use categories to decorate it / configure it in different ways -- but If you really need to work with a different subclass then you will have to set those up in your MOMD for core data to be able to instantiate them properly for you.
One last, last suggestion. Not sure if you are familiar with a tool called MoGenerator? It generates a matching set of classes -- one private that represents your actual MOM class and another public that you can extend with additional logic. Anyway, it looks like it has a pretty clever way to wrap your entity with the inner private version -- which creates as _Mail -- and then exposes a public version Mail - that you can then modify. All the plumbing is in the _Mail class. (It also takes care of the drudgery of doing the wrapping). I think you might be able to use it to do what you want. Ie generate your models -- and then just create another ExpressMail subclass that inherits from _Mail. Again, I can't be certain and not sure it eliminates the downcasting issue - but maybe worth a try?
Anyway, check it out:
https://github.com/rentzsch/mogenerator
PostScript
I just tried this myself using Mogenerator. And you still can't add anything to a different subclass of your _baseclass that doesn't exist on the base. That is, I can't subclass the _Mail class it would generate (which maps to a Mail entity in the MOMD) -- to create eg ExpressMail -- and add any behavior that's not on Mail. Same problem as before. So see prior conclusions. Doesn't seem possible for some of the reasons already given.