On Jan 4, 2010, at 23:35, Rick Mann wrote: > I'm slowly but surely getting the hang of using multiple MOCs. I'm > successfully creating objects in MOC B and merging those changes into the > existing MOC A, and seeing the UI bound to MOC A update to reflect the > changes. > > The problem I'm seeing now is that MOC A then becomes dirty, and wants to be > saved. If I save it, I get a warning that "This document’s file has been > changed by another application since you opened or saved it. The changes made > by the other application will be lost if you save. Save anyway?" > > The thing that's a bit wonky here is that these changes are already saved in > the store, because that's how the MOCs got merged in the first place (the > dirty flag is being set by my call to > -mergeChangesFromContextDidSaveNotification:). There's definitely no other > app involved. > > The changes in MOC B consist of all new objects, and a relationship between > an old object and a new one. This is a to-many relationship, that is, the old > Group entity picks up another Part entity. > > Am I doing something wrong, or failing to take some step to avoid this > confusion? There may be legitimate changes in MOC A that need to be saved, > but the merged changes should already be in the store.
Are you using NSPersistentDocument? In that case, the Core Data 'save:' is integrated into the document save mechanism, and additionally calling 'save:' yourself is going to mess up the document state in precisely the way you described above. That said, the problem is just that the modification date of the opened document file has changed since it was originally opened (because of the Core Data 'save:' call), but there's nothing really wrong. It's supposed to be possible to call -[NSDocument setModificationDate:] to update the document's internal state, and the warning should no longer appear. (However, whenever this comes up on the list, the OP usually seems to come back to report "it doesn't work". Finding the right place to put this call seems to be a challenge.) Even if you can cause the warning to be suppressed, also consider what you are actually doing, which is destroying the standard/expected document metaphor. Once you call 'save:' outside of the context of a document save, you can no longer revert the document, or close it without saving changes (in the sense of leaving the original untouched), and Save As... won't have the usual semantics. There may well be undo-related issues as well. The very fact that you need to call 'save:' yourself is a strong indication that a document architecture isn't really a good fit with your functional requirements. I understand that the standard document behavior is very convenient and compelling, but the marriage of NSDocument and CoreData is uneasy at the best of times. _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
