On Jan 16, 2009, at 17:26, Barry Wark wrote:
In fact, that's how I started. It works fine (using a separate entity for the data), and performance was fine. Unfortunately, the backup system at the deployment site backs up entire changed files (rather than binary diffs), so the continuous changes to flags and metadata in the data model during analysis force a back up of all the original BLOB data as well... order 100GB/day. Thus, we've decided to go with the separate file solution. Since this is, in fact, the Apple recommended approach, I was surprised it wasn't easier to implement.
If the BLOBs themselves are not being changed (at least by this application on a per-document basis), then you could keep a "library" of BLOB sets in the Application Support folder or somewhere shared.
Or, even if the BLOBs are changed sometimes, you could try putting them in a separate persistent store that you add to your managed object context, and use cross-store links. It's *possible* that a simple Save will not touch the BLOB store if the BLOBs haven't changed (though I have no idea if that's so or not). In that case, your backup system won't try to backup the unchanged store. You'd have to try this out for feasibility, and it means messing with cross-store links, but the big win is of course that you don't have to get your hands dirty in the save process at all (I think).
_______________________________________________ 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
