Re: Getting warning when saving merged MOC
Re: Getting warning when saving merged MOC
- Subject: Re: Getting warning when saving merged MOC
- From: Quincey Morris <email@hidden>
- Date: Tue, 5 Jan 2010 11:56:50 -0800
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 (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