Propel

Pros – First, let’s be clear I’m not talking about the pros of using an ORM. I’m talking about the good things that this ORM implementation brings to the table. Those are:

• Hydration Speed – You can argue you should never retrieve hydrated PHP objects from query if you don’t plan on taking some sort of save or delete action on it. Yes, that’s true from a performance standpoint, however, if you are building a site where performance simply isn’t a concern then you’ll be pleased to know Propel can hydrate a set of objects quickly enough to be used in building a view (i.e. a data grid of some sort).
• Classic Getters/Setters – You get these methods stubbed out in the base classes that Propel generates and you can override them easily. I should note Doctrine can do similar sorts of things but not in a conventional way.
• Support – The Propel mailing lists and IRC channel on freenode are pretty active, thought, not near as active as Doctrine’s.

Cons

• Dependency hell – Propel has improved this but it’s still not perfect. Back in the early days, before PDO, you needed Propel’s generator, Phing and Creole. Now you just need the generator and Phing. Phing is very much like Java’s Ant build tool. While I understand and get why they use Phing, it adds a layer of complexity that makes it a barrier to new users. Propel’s generator isn’t as bad as it is just a set of Phing targets to do Propel’s bidding. If you come from .NET or Java using Phing won’t be a big deal but if you aren’t familiar with Ant or nAnt then Phing will come with a learning curve.
• Criteria – Propel’s way to help ensure portable queries are built is via their Criteria object. While I get the need for it, not having a explicit way to run native SQL short of getting a PDO connection and doing all the work that way is a short coming. In fact, I despise Criteria so much I never use it, mainly because it doesn’t take too much work to hit a situation that Criteria either can’t handle well or make the code so complicated it’s not worth it.
• No 5.3 namespace support – Let’s face it, we are all tired of Really_Long_Class_Names ala PEAR, Zend Framework, et. al.
• Community – This is probably hard to blame on any one person but for a long time no work was done on Propel. There was a change in project leads which took a long time and the development efforts took a while to get going. I’m happy to say the team is active again, but a lot of ground was lost during the downtime.

Doctrine

Pros

• No other dependencies. Doing builds is easy as creating a simple PHP command line file and running it. No Phing, no other external property files.
• Magic finders – I love this. Say you have a user table with a user_name field that has a unique index on it. Retrieving this is as simple as

  Doctrine::getTable('User')->findOneByUserName('janedoe');

  . Propel would require a few more lines setting up a Criteria object and running it.

• Named Queries – This is something I pitched to the Propel development team quite a long time ago that always got a luke warm reception from the community. I ended up implementing my own named query implementation which worked well enough that I never used Criteria. With Doctrine you just get it out of the box:

  $this->addNamedQuery(
      'someQueryName',
      \Doctrine_Query::create()
          ->select('*')
          ->from('User u')
          ->where(user_name = ? AND 'password = ?')
  );
  

  Now I’m not totally in love with that syntax, it’s not much better than Criteria, honestly, however I go through that pain once and then I can just say:

  $user = \Doctrine::getTable('User')->find('someQueryName', array('janedoe',SHA1($password)));
  

  It’s also worth noting you can also use named queries to issue raw SQL, though, it will only return the raw recordset. Some of you are probably asking WTF? Named Queries? Read up on them, decide for yourself if they are for you…all I can say is after having used an implementation for years I’m sold on it (maybe that can be a future blog post).

• Documentation – Their documentation is top-notch. Only improvement that is needed is comment support to the manuals.
• Community – Let’s face it. Doctrine has gained some traction and all you need to do is follow the mailing lists, IRC and other community resources to see they simply get it. Their partnership with Zend Framework is a shining example of good strides in this area.

Cons

• Hydration Override – This one had me scratching my head the first time I noticed it. By default, if you fetch an object by the same primary key twice you don’t get two different copies, you get a pointer to the most recent version. On the surface that makes sense but there are a number of reasons I don’t like this as the default setting. Luckily you can turn this off through a configuration setting when you initialize Doctrine.
• Hydration Speed – This is my biggest complaints with Doctrine. If you run a query that pulls a parent/child relationship (i.e. a customer and their orders) this take a lot of time with Doctrine’s hydration method. The complexity is the circular references you can get. I don’t know why Propel handles this so much better but the impact is you can’t use Doctrine’s hydrated objects in you views. The way around this, I’ll call the Doctrine Way, is to have them hydrated as arrays. You still get the parent’s children, you just aren’t working with a native PHP object. When you think about it, it make sense, though I still prefer having a choice. The performance hit you take, even on simple queries, makes the array hydration mandatory if you are pulling more than one or two records from the database.
• No 5.3 namespace support – It too doesn’t support namespaces yet.

This isn’t meant to be a comprehensive review of either system, rather, a punchlist of noteable things. I don’t feel this blog post is near comprehensive enough to base your decision on, rather, it can be used in addition to your findings. I’d love to hear the other pros and cons from either camps.