On Apr 7, 2008, at 12:10, Chris Hanson wrote:
On Apr 7, 2008, at 1:50 AM, Quincey Morris wrote:
Yet a core principle of Core Data is its abstraction of the model
away from the structure of the various persistent store formats.
Core Data already offers the ability for developers to use an
arbitrary schema for a persistent store: You can subclass
NSAtomicStore and use it to implement any schema you like for your
persistent stores, with the constraint that you will get atomic load/
save semantics instead of transactional load/save semantics.
This does not in itself let you use an arbitrary database schema
with an SQLite persistent store. But it does demonstrate that doing
so would not be an abandonment of any principles that you seem to
have inferred.
I think we are talking about different things. I am not, and never
was, talking about file formats, although I admit that the sentence
you quoted fails to make this clear.
The question is this:
What administrative information -- that is, what data and data
structures apart from the actual modeled data, and apart from the
administrative information that is present in all sqlite databases
anyway -- does Core Data in general require its sqlite persistent
stores to store?
1. If the answer is literally "none", then it would appear that Core
Data could already use an existing sqlite store as its persistent
store, merely by writing a suitable model description for it, because
everything it needs would be in the database already.
2. If the answer is "some", then where would that administrative
information come from, if you were able to hand Core Data an existing
sqlite database? You could (a) do without its being stored, or (b)
create it and add it to the existing database, or (c) refuse to use
the database.
It appears (based on the comments earlier in this thread) that the
answer for EOF is either 1 or 2a.
It appears (based on past discussions on the list, which of course
could have been simply wrong) that the current answer for Core Data is
neither 1 nor 2a.
2b doesn't really count, since it's not really using an existing
database if it reconstructs the database with a different set of data
structures.
That leaves 2c, doesn't it?
If you're saying, as an expert on Core Data, that Core Data could
reasonably changed so that the answer would be 2a, without affecting
its internal functionality or performance so greatly that Core Data
would need to be significantly re-architected, then I would ask: what
is that administrative information *for*, if it is so little
disruptive to be without it?
_______________________________________________
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 [EMAIL PROTECTED]
