eZeAR_ActiveRecord implemen...

Searching for existing ORM solutions

So the model layer was quite an important item in my search for The One True Web Application Framework(tm). As we already have a home-grown framework at work, I'd use the TOTWAF(tm) mostly in my spare-time project, so everything has to be as simple as possible - I don't want major headaches in my spare-time . I've been using PHP5 exclusively for quite some time now, so everything would have to work well with PHP5.1 and up. DataObject works okay with PHP5, but essentially is a PHP4 package, and also it is based on userland abstraction layers such as PEAR::DB or MDB2.

Propel

The most viable option for PHP5 clearly is Propel. Without a doubt, it's the most advanced ORM layer out there. I had read about Propel before and I've always liked the concept. The implementation seemed very clean from an object-oriented point of view. Then I tried the Symfony framework. which features tight Propel integration. Having to work with Propel, it suddenly became much less appealing. It just... felt.... bulky. Unintuitive. Bloated. Stuff like that. Too many method names to remember, too big an API. I want to use databases intuitively, I don't want to have to consult the manual everytime I try to fetch something. If I wanted that, I could use Java. Wait, Propel was inspired by a Apache Torque. Ah, there's the explanation Another shortcoming (in my eyes) of Propel - just as DB_DataObject - was that it used a userland abstraction layer. Creole, in this case. PHP 5.1 has PDO now, which I like a lot. I don't use PHP4 anymore, so a userland abstraction layer would mean mainly one thing: Unneccessary slowdown.

Rails' ActiveRecord

While trying Ruby On Rails, I've come across their ActiveRecord implementation. By god, it is simple. This was I had been searching for. It is so simple, even a 5-year-old could use it. Despite its simplicity, it is also very powerful. You can still dynamically join in data from related tables at runtime, and much more. I was also very impressed by the migration features - basically, you can keep your database schemas up-to-date and/or roll back to a previous schema version without ever having to write any DDL statements. Plain cool. One problem, though: Rails is written in Ruby. I've tried getting comfortable with Ruby syntax. But really, it's plain ugly. It just screams ugly right in my face. I need curly braces, damnit I think that C-style syntax has really grown on me. I started out with languages like Basic and Pascal - and these days, whenever I see Basic code, or Ruby or Python or anything not C-style for that matter, it looks kinda alien to me. So thanks but no thanks. I'll stay with PHP. Well... until something better comes up or someone offers me insane amounts of money

Rolling up my sleeves...

Okay, enough chit-chat. What I basically want is something that is as simple as Rails' ActiveRecord, works well with PHP5, plays well with the Zend Framework (that I'm building my stuff on) and uses pure PDO calls without additional abstraction layers in-between. Unfortunately, there seemed to be nothing that fit that description. So, I had to roll up my sleeves and do it myself. As beginning with a brand-new library was a real good opportunity to try out unit testing, I decided to install PHPUnit and make it my first experiment in test-driven design as well. Just to summarize: I don't see myself testing every single aspect of a whole application with unit tests, but for libraries, I don't want to go back The idea of eZeAR_ActiveRecord is to have all table fields defined as class properties in the table classes. The folks at Zend don't want to do this for their own upcoming implementation, but I find this a better solution than looking up the info in the database, caching the result and reading the cached result back in on every request... that just screams overhead to me, so I'm very interested in how exactly they're going to solve that. Another reason why I want fixed class properties is so that I can use Zend Studio's code-completion with the field names - this way I don't have to remember the names of the database fields in each table (I have a really bad memory, you know ). Ruby's ActiveRecord has a really cool feature: You can pull in related information from other database tables just by accessing a previously undefined class property having the same name as the related table. Say, you've got a "customers" record loaded and want to iterate through all "orders" from the so-named table. This would look like this: I wanted the same feature for my implementation, and having all existing table fields as physically defined properties allowed to easily distinguish between existing fields and dynamic access to related tables, using the magic __GET() method. In the framework that we use at work, we achieve something similar using the ArrayAccess interface from SPL, but I like it better to have only one type of property access and not having to guess whether I really access an array or if this is really an object behaving like an array.

How to use eZeAR_ActiveRecord

To make a table accessible via ActiveRecord, all you have to do is to define a class having the table's name (with the first letter capitalized, though, to make it lookbetter). You will also have to add all the table fields as public class properties. I make some assumptions about your schemas naming scheme: All table and field names in the database have to be completely lowercase and the primary key for each table has always to be a field called "id", which also has to be an auto_increment field (or SERIAL or whatever your database calls it). The only kind of override currently implemented is for the table name - by implementing a tableName() method you can have a class name different from the table's name. But you can't yet override the assumption that there always is a primary key called "id". Another assumption is that foreign key fields are always named like "{foreign table name}_id". Here I'll have a table "order" link to the "customer" table: Now it works like this: Whenever you have a customer object loaded and access its non-existing property "Order", ActiveRecord will try to find the "Order" class (thanks to autoLoad()), fill its customer_id property with the value from the customer object's "id" property and issue the order object's find() method. Cool, isn't it? This also works for 1:1 relations - imagine if each customer could have only one order... okay that's a really stupid example, but remember the blog title ... where was I... ah yes, okay so if I didn't have the customer_id field in the order table but put an "order_id" field inside the customer table, I could also pull in the single order record that way: What doesn't work yet are n:m relations using crosslink-tables - this has yet to be implemented, but probably won't be done before I really need it When I do implement it, I will most likely stay close to how Rails' ActiveRecord implementation handles it - they have a ":has_many through" property for that.

The future

Also still missing is the other side of the coin - I'd really like to be able to insert related records automatically within a single transaction together with the originating record. That is, if I wanted to add a new customer I'd like to automatically add an order and a few order items just by creating the proper objects and putting them into their parent tables' properties - like this: By saving the top-level customer object, the newly-generated id of the customer record would be used to populate the order object's customer_id property. When saving the order record, its new id would then auto-connect the item records with the order, most probably using the obligatory crosslink-table - all in one single transaction. As I said, all that is not yet possible, but I'd really like to go in that direction. Propel, for example, has a similar feature. For saving records, I only have one method: save(). It will determine whether or not the id property has been empty at object instantiation and then build an UPDATE or INSERT statement, depending on the outcome. Selecting records is also very easy: I can pass an id to the constructor when getting a specific record, or I can create an empty object instance, fill the properties I have values for and call find() - all filled properties will then serve as WHERE conditions in the resulting SELECT statement. For iterating through result sets, you currently have two options. The first is a blatant rip-off from the way DB_DataObject works The other method is taking the PDOStatement object that find() kindly returns and looping over that directly. This has the disadvantage that you'll have to take care of closing the statement yourself after you've used it, so that other statements can be issued again (this may or may not be an issue, depending on what DBMS you're using). In the future, I'd like to implement the Iterator interface, so you can use ActiveRecord objects in foreach loops directly. If you scroll waaay back up, I briefly mentioned Rails' migration feature - remember, that nifty little feature that makes switching between schema versions a breeze. I really like that, but I'd be in way over my head if I wanted to code that all by myself - I just don't have that kind of time. Luckily, it's something that MDB2 already offers, so I'll use its schema management features on the command line to achieve this. Including MDB2 doesn't hurt, as it will not be used at runtime but only when really needed to perform a specific task. The final thing that's missing is a simple method to add custom WHERE conditions, so I can use thinks like BETWEEN, LIKE and all that in my queries. For simplicity's sake I currently envision something like DataObject's whereAdd() method, the difference being using PDO placeholders to make use of prepared statement support, like this: This would find all orders from a specific customer within a given time span. As this is very simple to implement and is also something that would be used quite frequently, I think this is what I'll do next

Where's the code?

If you're interested in using ActiveRecord, here's a temporary link to the Subversion repository: https://ssl.limbourg.com/svn/activerecord/trunk/ You'll notice that the eZeAR prefix is still missing - that's because I haven't yet set up an official repository that will contain all the eZeAR components and I finished the first version of ActiveRecord before I came up with that silly name. I haven't fully decided on a license for the code yet, but expect it to be something along the lines of the BSD license or a Creative Commons equivalent.

You've made it !!!

If you've read this far, you definitely have too much time on your hands and need to get a life No seriously, I hope this wasn't all too boring and please, by all means, feel free to comment. I'd really like to hear what other think about this topic and this kind of ActiveRecord implementation. Also, I strongly hope this will be the only component that I'll have to create from scratch and that everything else can be achieved by simply extending existing stuff, so that the next blog entries will be considerably shorter