CoreData file format stability
CoreData file format stability
- Subject: CoreData file format stability
- From: Charles Srstka <email@hidden>
- Date: Tue, 3 Jun 2008 01:12:58 -0500
Okay, after many years of pretty much only doing software that had to
run on very old versions of Mac OS X, I've finally decided to do some
stuff that might require Tiger or maybe even Leopard, so I've been
able to start exploring some of the various new features Cocoa has
picked up over the years, such as bindings and such. Now, I'm having a
look at CoreData. It looks neat, but I do have a couple of questions/
concerns about it. The first of these is:
1) The file format for saved files. I'd rather not make some
proprietary/closed Microsoft-ish thing - I'd like it to be possible
for other programs to read/write my file format, including
hypothetical programs that might get written for other platforms so
that my file format could possibly be readable and writable by our
Linux friends (and Windows carbon units as well). Since CoreData has a
SQLite-based format, and since SQLite is available pretty much
everywhere, this seems pretty good as long as I am able to figure out
how CoreData sets up the tables and such in its documents, except for
one concern: what if the layout of the SQLite file CoreData creates
changes? If CoreData on 10.6, 10.7, etc. all generate SQLite files
that are set up a bit differently from the way the previous version of
OS X did it, that could create a very annoying moving target for
anyone trying to access the files via a non-CoreData means. Now, one
would think that would not be likely to happen, since it could
potentially cause a very confusing situation where the same exact
binary would create a different file format depending on which OS
version it was running on, but then again this *is* Apple we're
talking about, so I'm a little paranoid. Is there any documentation
anywhere promising that the format of the CoreData save files won't
change in future versions of the OS, or failing that, could one of the
Apple employees here let me know if this is a valid concern or not?
2) Is CoreData able to edit files in place at all? The reason I am
asking is because the documents my hypothetical app would work with
could possibly become very large, maybe even in the 300-400 MB range.
Would CoreData be able to just open the files, let me search them, add
stuff to them, etc., like one would normally be able to do just by
using SQLite directly, or would it be copying the whole thing into a
store file somewhere or into RAM every time a file is opened?
Basically what I need to do at this stage is determine whether
CoreData is suitable for my hypothetical app, or whether I should just
roll something myself using the SQLite3 APIs directly. As always, any
help is greatly appreciated.
Thanks,
Charles
_______________________________________________
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