Re: Core Data: During Migration, should use Primitive Accessors only?
Re: Core Data: During Migration, should use Primitive Accessors only?
- Subject: Re: Core Data: During Migration, should use Primitive Accessors only?
- From: Quincey Morris <email@hidden>
- Date: Tue, 16 Nov 2010 16:51:47 -0800
On Nov 16, 2010, at 15:55, Jerry Krinock wrote:
>> You should be able to use the standard KVC accessors during migration, NSManagedObjects will respond to the foo/setFoo: laccessors for properties defined in your managed object model.
>
> Well, -foo and -setFoo: won't even compile unless I change the type of the sourceInstance: parameter of the method to be a MyManagedObject* like this:
>
> - (BOOL)createDestinationInstancesForSourceInstance:(MyManagedObject*)foo
> entityMapping:(NSEntityMapping*)inMapping
> manager:(NSMigrationManager*)inManager
> error:(NSError**)error_p
>
> or else do some equivalent typecasting in the implementation.
I think you're mixing up two different things here.
1. Regardless of whether we're talking about migrating or just using Core Data stores, *any* NSManagedObject, including vanilla ones whose entity doesn't name a custom subclass, has accessor methods for all of the properties in the corresponding entity definition. But the compiler doesn't know that these accessors exist, so you can't use them in source unless you arrange for @dynamic declarations of them, for which there are a couple of semi-automatic procedures.
I guess to make such declarations usable, you could just *declare* subclasses and use subclass-typed pointers in the source code, even though the class is still officially NSManagedObject.
I guess this oddity doesn't normally come up in non-migration scenarios, because if you want to make the dynamic accessors visible to the compiler, you'd likely specify a subclass in the entity, even if you don't actually override any accessors.
2. If you have a *custom* NSManagedObject subclass (i.e. whose subclass name is known to the Core Data entity), you can of course override the Core-Data-supplied accessor methods by writing your own. Adam was saying that there isn't supposed to be any legal way to use such custom subclasses during migration. All you've got are objects of class NSManagedObject, which notwithstanding their class have the dynamic Core-Data-supplied accessors.
I guess this kind of blurs the boundaries of what a class is, since different instances have different APIs, but that's actually nothing new -- you could always extend the class API on a per-object basis via things like 'valueForUndefinedKey:'.
TBH, I never thought all this through explicitly before, but this is how I think it works, unless my brain has gone into meltdown again.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden