Sunday, June 26, 2005

Refitting with Core Data

I have a project InCDius 2 with which I demonstrate my coding skills, and update my Cocoa skills. I know I have some users out there, and I'm thankful for them, but it's mainly about me, about either getting me jobs or educating myself.

One of the big new technologies in Mac OS X 10.4 Tiger is Core Data. Core Data is gives you two things: it makes it very easy to create a document or a database for your your Cocoa applications, and it allows you to add functionality without writing code. I'm mostly interested in moving to an Apple maintained database framework; I've used Sleepy Cat's Berkeley DB libraries for the back store of InCDius and I have never been satisfied with the result. I do not have the time to learn the libraries complicated and obscure API well enough to give a rock solid and efficient user experience. I cobbled a usage together once, and it works OK and is quite fast, but people report occasional corruptions. I'd rather use a database with a pre-existing Cocoa API which Apple is actively developing, and I don't have to worry about getting a static library to link properly with a x86/PPC universal binary.


Anyway, I want to refit the database in my pre-existing application. This would be a lot easier if I were writing this from scratch or there wasn't an installed base of people with their carefully filled databases, or if some users weren't still on Panther. So I need to support both databases for a while.

So my needs are:

  • Code to translate from an old database to a new one.

  • Abstracted records where most of the application does not need to know how they were created or how they are stored

  • GUI to let the user know I'm switching the database over.

  • If I'm running under Panther or Jaguar, I have to be using the old database.

  • If I'm running under Tiger, I could be using either database.

  • If I'm running on x86, I need to be using only the new database, because I don't want to deal with endian issues or keeping two versions of the Berkeley static library compiled and linked in. It was painful enough to get it compiled in the first place on one platform.



As in most such things, the first and most important step is increasing the level of abstraction. The first rule of programming says that all problems can be solved with a high enough level of abstraction. We'll see.


BTW, if you are an InCDius user who's come across this entry. You can often fix database problems by opening up a terminal window and pasting in the following two commands (assumes that InCDius is installed in the Applications directory):


cd /Library/Application\ Support/Generally\ Helpful\ Software/InCDius


/Applications/InCDius\ /InCDius\ GH\ 2.app/Contents/Resources/ db_recover -c