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: Sun, 22 Nov 2015 13:23:19 -0800
- Feedback-id: 167118m:167118agrif8a:167118sTKIFfjZPa:SMTPCORP
On Nov 22, 2015, at 11:44 , Motti Shneor <email@hidden> wrote:
>
> 1. My app supports autosave in-place. This means each "save" practically recreates the whole document as temporary file, then replaces the document with the new one. Such behavior is reasonable for a relatively small document -not for my ever growing databases who easily reach 250MB. What is the point in using SQL persistence, with all its glorious transactions, and rollbacks, if CoreData persistence isn't used at all for autosaving? Saves will get slower and slower as document becomes bigger and bigger, not to mention the size of document-versions, and although BSManagedDocument saves in the background - this seems really awkward. Is there a better solution?
No joke, my advice is “don’t use Core Data”.
If you must use Core Data, then my advice is “don’t use the NSDocument architecture”. The point of what you say above is that the NSDocument architecture doesn’t actually match your *database* application design. In that case, why not use Core Data alone, and implement the nearly-but-not-quite document behavior yourself?
> 2. I must still support user explicit "Save" commands, because I allow auto-saving temporary invalid states of my model, and only validate and confirm integrity upon "real" saves. For that, I want to force the user to Save/Revert/Cancel changes when he closes the document, or quits the application.
The first thing that springs to mind would be to mark the document dirty after any autosave operation that saves unvalidated data. For example, invoke updateChangeCount: with the parameter NSChangeReadOtherContents.
I’m assuming you ensure validation on non-autosave saves. If not, your basic approach is flawed anyway.
_______________________________________________
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