Marcus Zarra discusses Core Data, which is a new framework that was introduced by Apple with the release of OS X 10.4 Tiger. Core Data replaces the need for building data objects and helps manage storing data in a flat file, XML file or SQLite database. Marcus walks you through some of the basic usages of Core Data and tells you why it is so useful.Also: The Eclipse environment is very rich, but there are just a few concepts and mechanisms that are essential to Eclipse-ness. This chapter introduces these concepts, defines some terminology, and grounds these concepts and terms in technical detail. The ultimate goal is to show you how Eclipse fits together, both physically and conceptually.
Core Data and the OSX Developer; Eclipse Rich Client Platform
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
the fact that SQLite is installed on the system make it super awesome to write web apps that make use of DBs…. for testing at least.
True; it will be interesting to see how well it would scale as a database beyond the scope that it was originally designed for – but like I said, it would have been better had Apple adopted something like Cloudscape, which has alot more grunt in regards to scalability and feature completeness.
The database backend is an implementation detail. The whole point about CoreData is to separate you (the developer) from the implementation; and that is done very well.
Of course, if SQLite doesn’t scale high enough for your specific needs, you’re basically SOL; there’s no way to swap out the backend in CoreData.
But there’s already a cloning effort underway (http://gscoredata.nongnu.org/, in its infant stages), so some day CoreData apps will even be portable.
The second link was just what I needed, only I need a version with a more straight to the point language (less purely technical). 😐
I’m still trying to figure out what Eclipse really entails and what it can do for me.
I like CoreData. I’ve used it in several personal projects and it does the job. My initial criticism of it was from a DBA perspective, until I realized that CoreData is merely a persistence mechanism, and that things like uniquing and constraints have to be done by client code or in custom NSManagedObject subtypes. Because my data stores are sometimes used from multiple apps, I have tended to write a shared framework to handle all the book-keeping. This works beautifully.
Not much experience or exposure to EOF, perhaps? I’d download the tutorials on EOF which still exist and are included by reference in Openstep books still available at Amazon.