On Jan 5, 2010, at 05:30:59, Quincey Morris wrote: > 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.
I grant that I'm using NSPersistentDocument in a nonstandard way. I have a Library of Parts (and a Group hierarchy). This Library is managed by a LibraryDoc which inherits from NSPersistentDocument, and I consider this use to be "standard." When the user creates a new Part, I instantiate a PartDoc (also subclassing NSPersistentDocument), and set its MOC to be a new one instantiated using the NSPersistentStoreCoordinator of the LibraryDoc. I consider this document to be "non-standard," and I override and manage the saving a little more directly: instead of presenting the user with a standard put file dialog, instead I show them a custom dialog for naming the part, and call -save: on the MOC. The LibraryDoc listens for the notification of the MOC save, and calls merge: to update it's MOC's state. All of this works as one would expect. From what I've learned of Core Data, this is intended use (of Core Data, perhaps not of NSPersDoc in my PartDoc class). It's when I make changes to the LibraryDoc's MOC and try to save that I run into this problem. Perhaps it will be enough to update the mod date; I'll try that tonight. I'm not sure what you mean by "the marriage of NSDocument and CoreData." Did you mean to say "NSPersistentDocument?" If so, this statement seems to suggest Apple's implementation is just buggy. Clearly, Apple intends the two to be used together. cheers, Rick _______________________________________________ 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
