On Wed, Dec 31, 2008 at 4:16 AM, Markus Spoettl <msappleli...@toolsfactory.com> wrote: > 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.
Quite the contrary, I'm afraid. Although without actually testing it, you can't know for sure. > 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. For safe save operations, AppKit writes the data to a temporary file on the same volume, and then swaps the old file with the new, which is an atomic operation. If it can't do that, it will rename the original file and write the new one with the old name. This is why absoluteURL or absoluteOriginalContentsURL won't necessarily jive with -fileURL (see the comment header for -[NSDocument writeSafelyToURL:ofType:forSaveOperation:error:] for more details). The upshot is that absoluteOriginalContentsURL will be a URL which you can use to access your existing on-disk data, whether or not AppKit has temporarily renamed it. --Kyle Sluder _______________________________________________ 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
