• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: which cocoa wrapper for sqlite should i get?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: which cocoa wrapper for sqlite should i get?


  • Subject: Re: which cocoa wrapper for sqlite should i get?
  • From: Scott Ellsworth <email@hidden>
  • Date: Mon, 5 Jun 2006 11:01:45 -0700


On Jun 5, 2006, at 9:18 AM, Paul Lynch wrote:


On 5 Jun 2006, at 16:37, kyle kinkade wrote:

too me it feels like with Core Data you didn't really have too much control with the data. it seemed like you built your models, plugged everything together with interface builder, and that was it, but i really wanted more from it, in the sense of having more direct access. and the resulting database file would need to be exchanged with other platforms.

[...]
Other platforms should be able to read your database; but you may have problems using Core Data on an SQLite database created elsewhere.

To be fair, though, Core Data does have limitations in its current release, based on the role Apple envisions for it.


It has a very specific schema design - it does not allow you to use a natural PK, for example. All objects are referred to by an opaque object id. This fits well with WO, and can work quite well, but if you intend to interact with data stores without this arbitrary object id column, say via hibernate, you will be fighting the framework a bit.

Further, Apple does not promise to keep the schema as represented in the sqlite file unchanged with future releases. Were I trying to model something that is meant to be read on many platforms, I would be very cautious about using a toolkit that might change schema on me. I might still use it, but when part of a cross platform app is a single platform toolkit, I budget some engineering to make sure they play nice.

Finally, there are optimizations that SQLite allows, but that Core Data does not. For example,

NSNumber * normCol = [NSNumber numberWithInt:1];
NSPredicate *predicate = [NSPredicate predicateWithFormat:@"(abs(%@ - normalizedColumn) / 2 < %@)", normCol, [NSNumber numberWithInt:3]];


where normalizedColumn is a column in my Core Data model. SQLite can handle this quite well - 'select * from foo where abs(1 - normalizedColumn) / 2 < 3)' and you will get results back in moments. The mapping from this NSPredicate to the appropriate sqlite calls is not there, so it is not easy to do with CD.

That said, Core Data does a lot of things very well. I would not look at it as a general interface to SQLite, though, as yet. I would look at it as an elegant solution for the data model problem Apple was targeting. I do hope that last is addressed some day, but we shall see.

Scott
_______________________________________________
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


References: 
 >which cocoa wrapper for sqlite should i get? (From: kyle kinkade <email@hidden>)
 >Re: which cocoa wrapper for sqlite should i get? (From: Paul Lynch <email@hidden>)
 >Re: which cocoa wrapper for sqlite should i get? (From: kyle kinkade <email@hidden>)
 >Re: which cocoa wrapper for sqlite should i get? (From: Paul Lynch <email@hidden>)

  • Prev by Date: Re: BigNerdRanch Cocoa Bootcamp
  • Next by Date: Re: nsslider subclass not responding to mouseUp:
  • Previous by thread: Re: which cocoa wrapper for sqlite should i get?
  • Next by thread: Large NSProgressIndicator
  • Index(es):
    • Date
    • Thread