Re: Learning SQLite by watching Core Data?
Re: Learning SQLite by watching Core Data?
- Subject: Re: Learning SQLite by watching Core Data?
- From: Andy Lee <email@hidden>
- Date: Mon, 23 Jun 2008 18:40:52 -0400
On Jun 23, 2008, at 6:13 PM, David Carlisle wrote:
I'm just studying the issues so far. The sqlite version doesn't
have to work just like the Core Data version, except on the
surface. I'm only beginning to get a grasp of how deep the
implementation differences would need to be.
Assuming the data model in your Core Data app wasn't too complicated,
a simple SQLite version could have four tables and four classes, one
for each entity. You could use FMDB, which Jens mentioned and which I
also like, to do simple reads and writes to the four tables -- a very
naive approach which would work fine in a simple application.
To get an idea of what Core Data adds on top of that, first consider
that it manages object *graphs*, not just simple flat records. As if
that alone wouldn't be a daunting thing to reproduce, consider this
list from the docs:
<http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/cdProgrammingGuide.html
>
[...]
* Built-in management of undo and redo beyond basic text editing
* Automatic validation of property values to ensure that
individual values lie within acceptable ranges and that combinations
of values make sense
* Change propagation, including maintaining the consistency of
relationships among objects
* Grouping, filtering, and organizing data in memory and in the
user interface
* Automatic support for storing objects in external data
repositories
* Optional integration with Cocoa bindings to support automatic
user interface synchronization
[...]
I believe Core Data also does sophisticated caching.
--Andy
As far as the filename extension, if I don't use the .sqlite
extension, then sqlite3 creates an empty textfile with the same name
as the database:
Last login: Mon Jun 23 14:19:24 on ttys000
10:~ idev$ sqlite3 SQLiteStudy1
SQLite version 3.4.0
Enter ".help" for instructions
sqlite> .dump
BEGIN TRANSACTION;
COMMIT;
sqlite> .exit
10:~ idev$ sqlite3 SQLiteStudy1.sqlite
SQLite version 3.4.0
Enter ".help" for instructions
sqlite> .dump
BEGIN TRANSACTION;
CREATE TABLE ... the data structures are dumped as expected here
On Jun 23, 2008, at 3:44 PM, Jens Alfke wrote:
On 23 Jun '08, at 2:35 PM, David Carlisle wrote:
I am studying an application design by implementing it with Core
Data, then studying how I would move it to a platform where only
sqlite is available.
Whew. If you want to implement an app the same way on a no-CoreData
platform, you're talking about basically re-implementing CoreData.
That would be a terrifyingly large and difficult task. Keep in mind
that CoreData has been in development in one form or another for
about 15 years (it does back to NeXT's Enterprise Object
Framework.) A lot of the magic inside NSManagedObject relies on
very sophisticated manipulation of the Objective-C runtime.
If you want to write an app that's portable between CoreData and
non-CoreData platforms, I would suggest using one of the existing
wrappers (QuickLite or FMDB) instead of CoreData. They're not as
powerful, but you'll be able to use them on both platforms without
having to change your code.
I'm happy with my approach. I modified ISavant's suggested Unix
statement, realizing I needed a .sqlite suffix after my document
name to make it work, so that answered that question.
SQLite doesn't care what the filename extension is, so that
couldn't have been the issue.
Ilan noted that Core Data does "undocumented voodoo" with sqlite,
which is good to be aware of.
And that statement was immediately denied by a CoreData engineer. I
have never heard of CoreData using any undocumented sqlite features.
—Jens
_______________________________________________
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
_______________________________________________
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