Re: Invalidated managed objects
Re: Invalidated managed objects
- Subject: Re: Invalidated managed objects
- From: Gideon King <email@hidden>
- Date: Sun, 4 Apr 2010 14:44:11 +1000
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.
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:
- (id)newReferenceObjectForManagedObject:(NSManagedObject*)managedObject {
NSManagedObjectID *oid = [managedObject objectID];
if ((oid == nil) || [oid isTemporaryID]) {
NSString *aUUID = [NMFoundation generateUUID];
managedObject.elementID = aUUID;
}
return [[NSString alloc] initWithString:managedObject.elementID];
}
It's really helpful to have your input on this - I spent forever looking for this, and didn't see it because I didn't fully understand when the reference object needed to be the same and when it needed to be different.
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.
Hopefully on the home straight now...
Regards
Gideon
>
> Okay. The invalidations are coming from the PSC when it removes the old store. At this point it's already added the new store, and it's already told the MOC to switch all the objectIDs from its MOs to point to the new store. The problem is that your custom store wasn't being honest about the objectIDs, it wasn't even saving them at all, so the remapping between the old and new store fails. At that point, the MOC still has objects from the old store in it, because the new store handed out random IDs and the mapping failed to find them.
>
> So I changed your save method to write out both the UUID and the string data so your store could properly reconstruct the cache node it loads.
>
> There was another subtle issue from your reusing the metadata dictionary to hold your row data. The problem is you set the metadata at unfortunate times, both before and after the store is created. Instead of changing it in -init (too soon) and in -load (too late), it works better to use -loadMetadata. This is a problem for you since you were overwriting the in memory metadata with the plist you wrote to disk which effectively caused the store to change it's UUID. The documentation isn't clear on this, so you shouldn't feel bad about missing this part. You also had -metadata spontaneously mutate the row data, which is bad.
>
> It's really important for stores to keep their UUID, and for them to hand back the same objectID for an object that they did when we asked before. Otherwise constructing a map from old ids to new ids and looking up stores by their UUID is kinda hard.
>
> I'll send you back the original and edited sample projects so you can diff them.
>
> - 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