The odd bit

Once is an accident, twice is a coincidence, three times is an enemy action.

The odd bit - Once is an accident, twice is a coincidence, three times is an enemy action.

Object/Relational Data Persistence in PHP

Another post about PHP and the topic is once again data persistence. I’m starting to wonder if this is my search for the Holy Grail…

I previously blogged about some differences in the implementations of the Zend Framework and the eZ components. Let it be clear, the Zend Framework’s implementation is also not the most logical one.

Something they have in common is that neither can cope with composite keys. No biggie you’d think until you encounter two entities with a many-to-many relationship. While there are ways to circumvent that problem, I’d rather have it working without trickery.

The real oddity in the Zend Framework comes when you start working with results from database fetches. The persistence starts by defining a PHP class that extends Zend_Db_Table. A fetch from that table results in an object of the Zend_Db_Table_Rowset class. Iterating over that object results in objects of the Zend_Db_Table_Row class. This means that one row from the database is not an instance of the persistent class. The real drawback of that implementation comes when you want to define custom properties on “persistent objects”.

An example of such a custom property: artists and songs. Each artist is an object of the Artist class. Instead of having to load the Song table yourself and query it for all songs of Artist A, it would be a lot handier if you could access all songs by using a property, e.g. $artist->songs.

If you would like to achieve such a thing with the Zend Framework, you have to start implementing your own extended Zend_Db_Table_Row classes and making sure all results are casted to the new type. Not good. Another possibility would be to implement something in the persistent class (the table’s class), but that’s even less logical.

So here I am… once again in search of a good implementation. Looking back at things, the data persistence implementation that ships with eZ publish is not that bad after all. Anyways, I hereby call upon the world to leave a comment if you know of any other data persistence implementations for PHP5.

P.S.: I’ve tried looking at Symfony, but I found its installation to be too cumbersome at the time (not to mention that I couldn’t download a required library). So there’s no need to mention that one.

Category: PHP, Programming
  • Jason Coward says:

    Hello Hans, just doing some research on the latest framework developments for PHP that include O/R mapping tools, and came across your post.

    Have you checked out phpdoctrine (http://www.phpdoctrine.com/)? I haven’t tried it myself, but it seems to be along the lines of what you are looking for, though it does require PDO (PHP 5.1+ or PHP 5.0.x with PECL extensions) and I’m not too sure on the status of the project.

    I myself was not satisfied with any of the solutions and started one of my own earlier this year, which I am calling xPDO (http://xpdo.org/) and releasing under GPL. It’s still in pre-release condition and lacking a lot of documentation. FYI: I have tried Propel/Creole, which Symfony uses, but it was way too heavy for my purposes, depended on Phing build scripts, and required PHP 5.

    xPDO also uses PDO, but also includes PDO emulation with a subset implementation so you can use it on PHP 4. It’s a little more specialized and slightly quirky (i.e. object fields are stored in an array rather than as actual PHP object vars) than many of the existing O/R mapping tools, but my main goals were to keep it extremely light, use only generic methods and accessors, make it work with PHP 4, avoid any attempt to provide SQL query abstraction, and instead focus on making it easy to port and optimize SQL to specific target platforms. And this is what I came up with.

    Cheers and good luck with your search for the Grail…I think O/R mapping is probably one of the larger controversies in framework design these days, and you’ll do well to pick from existing or craft a custom solution that meets your projects’ requirements best.

    Jason

    27 November 2006 at 21:24
  • splatch says:

    The ez Persistent Objects looks like Java’s Hibernate. Not at all, but ever names is similar (session, property, saveOrUpdate etc).
    I used in my projects Propel. This is not the best implementation but logic. There isn’t problems with Active Record stuff (i hate this pattern).
    The biggest problem with propel is relations. This library doesn’t support many-to-many relationship. From version 1.3 Propel switched from Creole to PDO and have good ideas (first level cache – identity map).

    From one year i don’t write anything in PHP but i thought about my ORM implementation…

    Regards,
    Luke

    13 January 2008 at 02:04

Your email address will not be published. Required fields are marked *

*