Re: [Leopard] Core Date migration lacks custom object classes
Re: [Leopard] Core Date migration lacks custom object classes
- Subject: Re: [Leopard] Core Date migration lacks custom object classes
- From: Pierre Bernard <email@hidden>
- Date: Tue, 6 Nov 2007 21:09:00 +0100
Hi Adam!
Thanks for the clarification. I have read the documentation several
times, but I missed that bit. In my mind this applied only for the
source model.
I find the choice to disable custom entities on the destination model
a bit odd. This will lead to business code being duplicated between
the MO and the custom policy.
I find it inconvenient in two situations:
- My entity persists a derived attribute. This attribute is refreshed
in awakeFromFetch and in the setter of the attribute it depends on.
Migration forgoes this mechanism.
- In my custom migration policy I use my custom classes. Given the
fact that initWithEntity:insertIntoManagedObjectContext: returns a
NSManagedObject creates the risk of runtime errors when calling
methods declared on the custom class.
Pierre
On Nov 6, 2007, at 8:39 PM, Adam Swift wrote:
On Nov 6, 2007, at 6:23 AM, Pierre Bernard wrote:
Hi!
I just noticed that during migration, Core Data maps all entities
to the NSManagedObject class rather than using the specified custom
class.
This causes me problems as my awake and validation methods are not
called and thus leave mandatory attributes with nil values.
This is by design and documented here: http://developer.apple.com/documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/vmMigrationProcess.html
The migration process itself is in three stages. It uses a copy of
the source and destination models in which the validation rules are
disabled and the class of all entities is changed to NSManagedObject.
Generally speaking, the data migration process has different needs
than the normal application usage of that data and you wouldn't want
or expect application-oriented behaviors during migration. By using
generic managed objects during data migration there's no risk of
unintended side effects during data reading and writing.
Migration is handled as a 3-stage process where source instances are
first migrated to destination instances with only attribute values,
then relationships in the second phase (so that at the relationship
migration phase you can reliably access both source and destination
instances' attribute values), and then lastly the model validation
rules are used to ensure the validity of the migrated objects before
they are saved to the destination store.
Use a custom entity migration policy and override
createDestinationInstancesForSourceInstance:entityMapping:manager:error
: to populate any derived attributes in your destination objects
(but only if you need them for the migration).
Hope that helps.
- adam
It also seems very wrong to me that when I create and insert
instances of my custom managed object classes within my custom
migration policy, the
initWithEntity:insertIntoManagedObjectContext: returns an instance
of NSManagedObject.
One can witness the problem using a custom migration policy:
@implementation ColumnAttributeMigrationPolicy
- (BOOL)beginEntityMapping:(NSEntityMapping *)mapping manager:
(NSMigrationManager *)manager error:(NSError **)error
{
NSManagedObjectContext *sourceContext = [manager sourceContext];
NSManagedObjectContext *destinationContext = [manager
destinationContext];
NSEntityDescription *sourceEntity = [NSEntityDescription
entityForName:@"ColumnAttribute"
inManagedObjectContext:sourceContext];
NSEntityDescription *destinationEntity = [NSEntityDescription
entityForName:@"ColumnAttribute"
inManagedObjectContext:destinationContext];
NSLog(@"Source class: %@", [sourceEntity managedObjectClassName]);
NSLog(@"Destination class: %@", [destinationEntity
managedObjectClassName]);
return YES;
}
@end
This prints out the following:
2007-11-06 15:17:33.872 HoudahSpot[1812:10b] Source class: (null)
2007-11-06 15:17:33.873 HoudahSpot[1812:10b] Destination class:
NSManagedObject
Best,
Pierre Bernard
Houdah Software s.à r.l.
---
Pierre Bernard
http://www.bernard-web.com/pierre
http://www.houdah.com
_______________________________________________
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
---
Pierre Bernard
http://www.bernard-web.com/pierre
http://www.houdah.com
_______________________________________________
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