Re: Bunch of CoreData based NSDocument questions.
Re: Bunch of CoreData based NSDocument questions.
- Subject: Re: Bunch of CoreData based NSDocument questions.
- From: Quincey Morris <email@hidden>
- Date: Mon, 23 Nov 2015 14:14:02 -0800
- Feedback-id: 167118m:167118agrif8a:167118sTKIFfjZPa:SMTPCORP
On Nov 23, 2015, at 12:50 , Motti Shneor <email@hidden> wrote:
>
> Any references to that old discussion? I’d like to read it. However, I think there should be a reasonable way to provide close-enough interpretation to NSDocument’s view of documents using CoreData's persistence. Database here is only means for partial saving of changes, without re-serializing the whole document. In the past there was a whole genre of applications who worked with very little Memory, by doing the same thing - reading small parts of their document into memory, and writing small changes to the document one at a time. Surely, the Document architecture acknowledges such applications.
No, it was in the vague past.
In the NSDocument metaphor, you must keep changes to a file (since the last save) separate from the file (in its state at the last save). Without that, you cannot revert, and you cannot close the document without saving. If you’re saving by applying the changes to a copy, you can fulfill the reversion/don’t-save requirement, because the saved document doesn’t replace the original until the last moment, *and* the replacement is an atomic file system operation that can only fully succeed or fully fail.
When you use a database with NSDocument, you can update the original file in place safely (assuming the database has transactions that can roll back an incomplete write), so there’s no need to copy the database for that reason. However, you can’t autosave, because that implies the ability to revert. Your current autosave is getting the ability to revert by making a copy of the database. If you don’t want that, you can’t autosave, period, since Core Data has no user-restorable checkpoints (AFAIK).
If you turn off autosavesInPlace, then you’ll have the old behavior, but you’ll have to trust Core Data never to corrupt your database if the app (or the system) dies in the middle of a save.
> My issue seems different, and can also be easily reproduced in other apps (e.g. TextEdit). Quitting it with a dirty document will quit immediately, and on next launch the document will be open with all last-session’s changes, and the dirty flag on. The last autosaved state can be used to “Save” the changes from previous session.
I’m sorry, I always get this wrong. It’s behaving correctly according to the autosavesInPlace==YES paradigm.
In this case, quitting the app does *not* cause any documents to be saved (or the user to be prompted to save), ever. It simply quits the app (well, it does an autosave first, if the document state has changed since the most recent autosave), and when you start the app again, the document is restored to its previous UI state, with the same windows open and the same dirtiness.
The reasoning behind this is that (in modern apps) it doesn’t matter whether it’s actually running or not, so long as it can be restored to exactly the most recent UI state if it re-launches.
So the problem isn’t that it’s quitting, but that your document isn’t being restored properly when it reopens (if it isn’t — maybe it is??). That might be because NSPersistentDocument (or your custom clone of it) doesn’t support state restoration at all, or because you haven’t implemented the custom restoration you need to really get back to where you started.
It’s beginning to sound like autosavesInPlace==NO might be a good starting point for clearing your list of problems.
_______________________________________________
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