In my last post, I started my search for a good object-relational mapper that I could use in my iPhone applications, since Core Data is not available on that platform. I had found FMDB, and ActiveRecord, but hadn’t started really using either, or stopped looking around for options. I have since discovered OmniDataObjects, which quite honestly is probably the most full featured, but least documented, ORM layer for SQLite. ODO also seems to have quite a few dependencies on other Omni frameworks. Not a huge deal, but I was looking for something as simple as possible. What I finally settled on was SQLite Persistent Objects.
I had actually started out working with ActiveRecord. I have done some Ruby on Rails work before, and the Objective-C version of ActiveRecord was close enough that I decided to give it a try. So I went through the process of creating my database, and initializing all the tables I would use. After that, it should have been a matter of defining my model classes as subclasses of ARBase, adding in their relationships, and then adding the SQLite connection call somewhere that will get called early in the application launch. And for the most part, it worked fine. Where I ran into trouble was with relationships between classes with multi-word names. I dug around for a little while the afternoon I found this bug, and it seemed to be some combination of the code that translated between the pluralized and singular forms of words (AR uses singularized class names, and pluralized table names), and the code that translated between camel case class names, and underscore separated class names. While it’s true that ActiveRecord is an open source project, I finally decided that if I could find a better working solution, my time would be better spent working on my own software, instead of fixing someone else’s libraries I was trying to use. Were I not trying to run a Mac software business on the side while witting Perl all day, I probably would have made a different decision, because there is definitely promise in ActiveRecord.
This is about when I started working with SQLite Persistent Objects. The pure simplicity of this library has floored me. There is no need to prepopulate a database with tables, or to even create the SQLite file at all. Just create subclasses of SQLitePersistentObject, and as long as all of it’s properties are either a base type (int, float, char, etc), another subclass of SQLitePersistentObject, or support NSCoding, that is all you have to do. The one thing that took me a bit to get used to is that unlike ActiveRecord, there doesn’t seem to be any easy way to have a “belongs to” relationship. This is because all “relationships” are handled as properties of the class, not as methods. “Has many” style relationships are typically NSArrays or NSDictionaries (or their mutable counterparts), and “has one” would just be a single sublcass of SQLitePersistentObject. Not thinking, I initially tried to setup a “belongs to” relationship by including the parent object as a property of the child, but that led to a nice infinite loop when I tried saving either the parent or the child. Obvious once I thought about it, but I had to try. Other than that one hiccup, I have been quite impressed with SQLite Persistent Objects, althouh I have not yet had the chance to do any real performance testing, as I am still waiting on my iPhone developer program application to be approved.
So, for my money, SQLite Persistent Objects is the current leader for a iPhone stand in for Core Data. ActiveRecord doesn’t seem to be there just yet, and while I’m sure OmniDataObjects is probably a great framework, I was able to get up and running with SQLite Persistent Objects much quicker.