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
