Re: How to manage a separate data file while saving an NSPersistentDocument or during schema migration
Re: How to manage a separate data file while saving an NSPersistentDocument or during schema migration
- Subject: Re: How to manage a separate data file while saving an NSPersistentDocument or during schema migration
- From: Quincey Morris <email@hidden>
- Date: Fri, 16 Jan 2009 15:00:19 -0800
On Jan 16, 2009, at 10:00, Barry Wark wrote:
I would like to encapsulate the management of this external file in
the model-related classes since I will need the same functionality
during schema migration. Thus managing the external data file in my
NSPersistentDocument's subclass seems wrong. Thus, in the object
model's root object, I create the external file in
NSTemporaryDirectory() in the root objects awakeFromInsert method and
store the NDAlias referencing the data file. I would then like to move
the external data file to the same directory as the saved data store,
when a save occurs. I thought didSave would be the appropriate place
to do it, but it looks like during invocation of the didSave method,
the persistent store is still in a temporary directory (presumably
before being FSExchangeObjects'd to create an atomic save operation).
FWIW, I spent quite some time trying to devise a way of getting
something like this to work, and eventually came to this conclusion:
That Way Madness Lies
but YMMV ("your madness may vary").
There are two sets of problems to deal with.
First, NSDocument doesn't guarantee any particular file handling
behavior at Save time, and you can expect that the implementation may
change in different versions of OS X. Also, the implementation may
well be different on different file systems, so the sequence of events
you observe on a local HFS+ volume may not apply to (say) network
volumes. Anything you choose to rely on may break at any time, unless
the documentation says otherwise.
Second, NSDocument is fundamentally invested in the concept of save-by-
copying for reasons of data integrity. As soon as you try to
*preserve* unchanged files across a save, the integrity of the save
metaphor is thrown into doubt. I'm certain that it's solvable (though
I'm also certain I'm not smart enough to do it myself), but only if
you have a solution to the first problem. Think about
NSPersistentDocument, and how it shoehorns Core Data into a NSDocument
environment. This was done by people at Apple who were certainly smart
enough, but even so there's no save-to (i.e. Save a Copy As ...), no
autosave, and save-as is implemented (AFAIK) as a Core Data migration.
So I think you have four options:
1. Go ahead with your original plan and hope it doesn't break on
future Mac OS releases or on different file systems.
2. Put the BLOBs in the Core Data object graph after all. (That's what
I chose. However, since you can't fault out individual properties,
instead of making each BLOB an attribute of its owning object, I made
it an attribute of an object owned by the owning object. That way I
could in effect fault out the BLOBs at will.)
3. Make your own NSDocument subclass that uses Core Data internally
(but not NSPersistentDocument), and replace the entire saving
mechanism by your own implementation.
4. Decide that your database is not really a document, and abandon the
entire NSDocument metaphor. You can still have housekeeping functions
for backing up versions of your database or snapshotting or cloning
it, without following the document model exactly.
_______________________________________________
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