On 22 בנוב 2015, at 23:23, Quincey Morris wrote: > On Nov 22, 2015, at 11:44 , Motti Shneor <su...@bezeqint.net> 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”.
CoreData has shorten this application's development cycle from years to 7 weeks of intense programming. It is a big application, with many aspects, including Microscopy imaging, measurements on live video, accumulating data while measuring it in database, and performing deep analysis over the accumulated data, exports, imports, lot's of UI and more. CoreData It is handling most aspects of my complex data scheme. Tons of relations and all. CoreData is great in object-graph management, and isn't bad at all at persisting too. Unfortunately, Apple has removed the original engineers from that project long time ago and the integration of CoreData with the document architecture is very neglected. Previous iterations of this program (It's its 3rd incarnation - a 25 years ongoing project) didn't use CoreData, but took years to write, and were way more fragile. It is impractical for me to give up CoreData on this project. > > 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? On my other side, My "DataBase" is really a document. self-contained, has a main window and several "satellite" windows, and there are several documents being open at the same time (for different researchers, using several microscopes in the same laboratory, taking turns at the computer). So it was SO convenient... I can write my own document management, but that takes lots of time and thinking, and does NOT work well with the OS's ever-developing requirements to integrate well with sleeping, waking, rollbacks, versioning, sandboxing, shut-downs, etc. etc. I DO WANT as much as I can get from Cocoa. I wish I knew enough to write my own MyPersistentDocument - but as I said - documentation is almost impossible to grasp (taking both sides - CoreData and Document architecture into consideration). > >> 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. > Problem is - the application quits immediately even when there are dirty documents open!!! the @#$@#$ document "architecture" feels free to quit because all has been "AutoSaved". not "Saved". I just want the old behavior - you should not be able to quit with dirty documents. That's all. I do have, of course, validation on saves (Hmmm.... CoreData has, and I added my overrides). But happy-happy-document-architecture doesn't really care. > I’m assuming you ensure validation on non-autosave saves. If not, your basic > approach is flawed anyway. > Motti Shneor --------------------------------------------------------- Ceterum censeo Microsoftinem delendam esse _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
