Re: Getting warning when saving merged MOC
On 05/01/2010, at 5:35 PM, Rick Mann wrote: 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. When doing things like this that you don't want the undo manager to pick up on, you just need to disable undo while you perform the operation, making sure you flush changes before re-enabling it: [moc processPendingChanges]; [[moc undoManager] disableUndoRegistration]; //do some stuff that alters the moc [moc processPendingChanges]; [[moc undoManager] enableUndoRegistration]; -- Rob Keniger ___ 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
Re: Getting warning when saving merged MOC
On Jan 5, 2010, at 00:07:55, Rob Keniger wrote: On 05/01/2010, at 5:35 PM, Rick Mann wrote: 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. When doing things like this that you don't want the undo manager to pick up on, you just need to disable undo while you perform the operation, making sure you flush changes before re-enabling it: [moc processPendingChanges]; [[moc undoManager] disableUndoRegistration]; //do some stuff that alters the moc [moc processPendingChanges]; [[moc undoManager] enableUndoRegistration]; Well, bracketing the merge call with that prevents the first MOC from showing as dirty, but if I make a subsequent change to it, and then try to save, I still get that warning that another app has modified the data, and those changes will be lost if I continue. ___ 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
Re: Getting warning when saving merged MOC
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
Re: Getting warning when saving merged MOC
On Jan 5, 2010, at 10:39, Rick Mann wrote: 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. Consider how this picture looks if you weren't using Core Data. You'd be opening a second NSDocument instance [which NSDocumentController won't do, btw, but ignoring that ...] on the same file, doing a save from the second instance, then seeing the first instance get confused. The *key* functionality of NSDocument is its careful and thorough approach to guaranteeing file-level atomicity of saving. A document is saved, or it isn't. The file [from the user's point of view] is not changed until the user explicitly saves, and the file [from the user's point of view] is never in a partially saved state. Violate those two principles, and your users will blame you just as soon as they accidentally modify files. What you're describing here is a database application, which has transaction-level atomicity of saving at best. (Core Data's 'save:' isn't a save in the NSDocument sense. It's more like a transaction commit, and that's precisely how you're trying to use it.) It's not at all obvious from your description why you need a second MOC to add a Part (or why that needs to be in its own NSPersistentDocument, though that's not the source of you headache, not yet). If it must be so then I suggest at least re-evaluating whether you should be using NS[Persistent]Document at all. Or, create the new Part in a separate persistent store and copy-via-insert rather than merge the objects. 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. It's intended use of Core Data, not of NSPersistentDocument. 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. I meant this marriage: NSDocument + Core Data = NSPersistentDocument. The implementation isn't buggy, it simply hides the full functionality of Core Data, and the full functionality of NSDocument. (Notice, for example, that NSPersistentDocument can't do a Save To... operation, and its Save As... is a little weird too.) ___ 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
Getting warning when saving merged MOC
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. TIA, 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
