On Apr 3, 2010, at 6:25 PM, Gideon King wrote: > Phew, that's a relief. I'll look forward to hearing what I'm doing wrong in > my sample project then. > > Regards > > Gideon > > On 04/04/2010, at 11:22 AM, Ben Trumbull wrote: > >> >> On Apr 3, 2010, at 5:07 PM, Gideon King wrote: >> >>> Wow, this is huge! Obviously the user doesn't expect the document to >>> disappear and a new one open up just because they did a Save As operation >> >> I have I'm afraid led you astray. The invalidated objects are not coming >> from the Save As operation. The managed objects in the MOC bound to the >> NSPersistentDocument, and any other MOCs bound to that same PSC will keep >> the NSManagedObjects themselves in sync with the underlying document even as >> it is remapped to a new file. I'll send you a sample project from the >> template that logs the notifications from NSManagedObjectContext and >> NSPersistentStoreCoordinator. The NSManagedObject pointers remain >> undisturbed.
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 (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
