Re: Accessing CoreData Sqlite db from outside Cocoa app
Re: Accessing CoreData Sqlite db from outside Cocoa app
- Subject: Re: Accessing CoreData Sqlite db from outside Cocoa app
- From: Ian <email@hidden>
- Date: Fri, 3 Mar 2006 23:13:09 +0000
Hi Greg,
I'll answer your points below:
On 3 Mar 2006, at 20:27, Greg Herlihy wrote:
There's nothing mysterious about the structure of the sqlite3
databases that
Core Data creates. It uses a standard relational database structure
with
entities as tables and columns to cross reference tables to establish
relationships.
Agreed, kind of ;)
There's nothing *too* mysterious, it's trivial to reverse engineer
the database by examining it's contents.
For example, in my case with my Template and User entities and the
relationship (many to many) between them I can see that User becomes
ZUSER, Template becomes ZTEMPLATE.
I think what I should've made clear in my original question was can I
always rely on 'Entity' becoming 'ZENTITY' so I can find it in the
database for example?
Relationships are a little harder to predict I think because the only
way I can see to do it is to reverse engineer the database, rather
than conform to some 'proper' method or other.
For example, the relationship between a User and a Template entity is
recorded in a table called 'Z_6USERS' (where did that name come from?).
This table has two fields - 'Z_6TEMPLATES1' and 'Z_7USERS' - whose
field entries are integer numbers that indicate the 'Z_PK' (primary
key) field of the ZTEMPLATE and ZUSER records respectively.
This is not a problem to reverse engineer, but I was asking if there
was some logic behind the naming convention of 'Z_6USERS' and
'Z_6TEMPLATES1' and 'Z_7USERS'.
But I don't see any advantage in reading directly from the sqlite3
database,
and personally I would advise against it. There is nothing in the
database
that would not be much more easily accessible via Core Data's own
classes.
Using Core Data classes to discover the structure, relationships and
constraints of the database has other advantages: most importantly,
accessing the database through Core Data will work with any kind of
underlying data storage: including XML, binary or a custom back end.
Furthermore, a program that uses the Core Data API is much less
likely to
break with future versions than one that relies on undocumented
sqlite3
database structures.
Absolutely - I couldn't agree with you more!
In this particular case however I need to expose the database (read
only) via a web interface so I'm dishing the db's contents up from
php in Apache.
Initially I incorporated an http server into the Cocoa app that
manages the CoreData db but bottled out of this route as the web
server needs to be robust... Apache & php are tried and tested writ
large!
Greg
Thanks for the input Greg - much appreciated :)
Ian
On 3/3/06 4:07 AM, "Ian" <email@hidden> wrote:
Hi all,
I've searched and searched for help on this and can't find anything
of any real help so far:
Has anyone any experience of accessing the contents of a CoreData
sqlite db from outside a Cocoa app?
Since it's a regular sqlite3 db it's easy to peek into it from the
command line, or from PHP for example, but I'm not sure how to do
very much with what I see there.
For example, say I have a very simple app with a User entity, a
Template entity and a relationship between the two entities that
allows templates to 'belong' to users.
Examining the db from outside CoreData I can see the Template enitity
has become a ZTEMPLATE table, likewise User has become ZUSER.
I can browse the tables (eg; select * from ZUSER) but don't see any
way to browse relationships between the enitities.
Furthermore, as I add users and templates to the db from within my
app, CoreData adds all sorts of weird and wonderful tables presumably
to manage the relationships but these tables just contain numbers.
Anyone have a better clue than I do about any of this?
Many TIA
Ian
PS - I don't plan on writing to the db from outside CoreData as I
know this is dangerous, I just want to read from it.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden