Re: Storing NSDocument data in packages/bundles
Re: Storing NSDocument data in packages/bundles
- Subject: Re: Storing NSDocument data in packages/bundles
- From: Markus Spoettl <email@hidden>
- Date: Wed, 31 Dec 2008 01:16:07 -0800
On Dec 31, 2008, at 12:57 AM, Kyle Sluder wrote:
On Wed, Dec 31, 2008 at 3:51 AM, Markus Spoettl
<email@hidden> wrote:
My app stores a lot of data in a document, potentially hundreds of
megabytes. The problem with using single files and NSKeyedArchiver
is that
one has to write everything, even if only a tiny part of the
structure
changed. My data is clustered into handy little pieces which could
be saved
into their own separate files within the package.
Have you thought of using Core Data instead? This is what the SQLite
store is designed to address.
No I have not, but I have a feeling that it wouldn't be suitable. The
data I store contains (when the document is big) millions of double
values (amongst other things) spread across hundreds of thousands of
objects. If the performance of NSKeyedArchiver is any indication the
system wouldn't scale very well. It is an assumption and it might be
totally wrong but I guess the overhead of keyed archiving is
significantly less than that of Core Data.
The problem is that - if I understand it correctly - when using
file wrapper
-fileWrapperOfType: of NSDocument, I always have to provide the
complete
wrapper, including all contained wrappers. That of course is
exactly what I
hoped to avoid because it means I'd have to write all data (this
time into
separate files/wrappers).
That is correct. You have to implement -readFromURL:ofType:error: and
-writeToURL:ofType:forSaveOperation:originalContentsURL:error: if you
want to go the document-package route and not wind up with wholesale
writing. This means, of course, that you need to be able to tell what
has changed in the document, and then be able to determine which
fragments need to be updated on disk.
That's no problem, that information is available. The documentation
for -writeToURL:ofType:forSaveOperation:originalContentsURL:error:
states:
----------
The value of absoluteURL is often not the same as [self fileURL].
Other times it is not the same as the URL for the final save
destination. Likewise, absoluteOriginalContentsURL is often not the
same value as [self fileURL].
----------
which is a little problem because to update my packages I need to
original location. Do you have any insights as to what "often not the
same" in this context might mean? To write the diff into the package
I'd have to have access to the package. It doesn't sounds as it that's
guaranteed.
Regards
Markus
--
__________________________________________
Markus Spoettl
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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