Re: Invalidated managed objects
Re: Invalidated managed objects
- Subject: Re: Invalidated managed objects
- From: Ben Trumbull <email@hidden>
- Date: Sat, 3 Apr 2010 22:37:19 -0700
On Apr 3, 2010, at 9:44 PM, Gideon King wrote:
> Excellent, thanks for that. I thought that once a managed object ID had been assigned, that newReferenceObjectForManagedObject: should always return the same value, so I was regenerating it from the previous data instead of generating a new one if it either had a temporary object id or no object id. I will switch over my code to do this.
Uhm, that's not exactly what I said. It should look something like:
- (id)newReferenceObjectForManagedObject:(NSManagedObject *)managedObject {
id result = nil;
NSManagedObjectID* oid = [managedObject objectID];
if ((oid == nil) || [oid isTemporaryID]) {
CFUUIDRef uuidRef = CFUUIDCreate(NULL);
CFStringRef uuidStringRef = CFUUIDCreateString(NULL, uuidRef);
result = [[NSString alloc] initWithString:(NSString*)uuidStringRef];
CFRelease(uuidStringRef);
CFRelease(uuidRef);
} else {
result = [[self referenceObjectForObjectID:oid] retain];
}
return result;
}
although all the Core Data stores use a single 64 bit integer with the current seed value stored in the metadata instead of UUIDs.
> In my current implementation, I have a base class for all my managed objects that has an id string (elementID) set in it. The only times it is persisted is for objects that I need to refer to in relationships. This means I can regenerate the value from the managed objects if necessary, so my new method will look like this:
The objectID value ("referenceObject") needs to be the same every time you load the document. If you open the document multiple times, and give the same objects different objectIDs, badness happens. For Save As, we're generating a dictionary of old IDs -> new IDs. When we add the new store to the coordinator, if the store hands back random values for the migrated objects, then the MOC can't fix its MOs to point to the new store's cache nodes.
if you:
(1) open the document
(2) fetch all the objects into array 'results' (with a sort ordering)
(3) NSLog(@"results = %@", [results valueForKey:@"objectID"]),
(4) close the document
(5) repeat steps 1-4
(6) compare the 2 logs
If the strings don't match, you're SOL.
> There is only one area of my code where this will cause an issue, where I pre-generate some of the xml for my file using some references to some managed objects. I'm sure I'll be able to find a way around this though.
>
> Hopefully that will resolve that issue.
>
> Also, I had not noticed the loadMetadata: method, so was just creating it in the init for new files, or in my load method for existing ones. I will have to do a bit of work to change that to load using loadMetadata: since I will have to extract the file from a zip file separately from the main load method which already unzips to a temporary folder. Not a biggie though.
You don't have to use it, but for the sample project you sent that conflated the metadata and raw data, it was the best way to avoid nuking the already loaded metadata when you loaded the raw data. It's probably all around better though.
- Ben
_______________________________________________
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