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 (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
