JasonEisen Open Source

Zend Framework and Doctrine

June 1st, 2008 jasoneisen Posted in Doctrine, Zend |

I’m currently working on a fairly complex (database-wise) project that makes use of nested transactions, and having failed to do my homework beforehand, a little while ago I came to find out the hard way that Zend_Db doesn’t support them (yet). After looking around rather quickly at my options I decided to use Doctrine as a replacement database abstraction layer. Although it is quite different the way it operates (Zend_Db is not an ORM like Doctrine), the fundamentals are somewhat the same, but even still every single one of my application’s queries would have to be rewritten.

Fast forward to now: 2.5 weeks later. I just finished converting the last few queries to use Doctrine. That’s a long freaking time, not only as far as project milestones and deadlines go, but a long time to not have any updates or changes to “visibly” show the client. Not that they were dissatisfied or unhappy, there are always hurdles to overcome, but it would be a lie to say they weren’t “on edge”.

Overall though, it has been worth the effort. Doctrine is a seriously serious ORM that makes querying the database fun again.

Here are some quick cons that I ran into for both:

Zend_Db:

• No Nested Transactions
• ->setIntegrityCheck(false) - wtf?
• Poor language normalization. Examples:
  • update($data, $where) instead of update($data)->where($where) - I’ve emptied a few tables due to this
  • $db->query() takes arrays to fill in your ?’s, but $select->where() doesn’t.
  • There are many more…
• Poor USING() support

Doctrine

• You cannot join tables and have the resulting record be one flat array, you are forced to use the ORM. For example, if you need to put all results into a CSV, you would need to access joined tables like $user->Group->group_name, instead of everything being flat like $result->group_name.
• Stack traces can (and will) crash your browser. They basically dump your entire database, and some. Hit the “stop” button on your browser before its too late!
• No USING() support. But the desire for this is replaced by the ease of how joins are written.
• Support can suck. I dare you to get on freenode and ask a question in #doctrine-dev (And good luck getting an answer in the main channel #doctrine). This is an area where Zend dominates everyone, though.

  Update: I have since found doctrine’s support to be very helpful. I think it is a matter of how much support you require, I was pretty needy there in the beginning. The whole database setup in the beginning with schema files has a very steep learning curve.

This is kind of comparing apples to oranges though, since one is an ORM and one isn’t, but the features that I need and the ones I have referenced above are features of both, so I thought I would share.

A side note and another benefit I have found while switching to Doctrine has been that I have probably reduced my code by a third, if not half. This may be due to the fact that my app is heavily database intensive, or it could be that the project was started while learning the Zend Framework this has given me the chance to go back and refactor old code, probably both. But in any case, the code is smaller and more effective than that written using Zend_Db. And the fact that Doctrine is only on version 0.11 shows a lot of promise.

So now, my previous ACL post is out of date (and now I see there are bugs in it ), I will post an update on here soon with the Doctrine replacement. And keep an eye on zomg’s blog in the next day or so, he’s been working on some things using Doctrine that I’m rather excited about.

Tags: database, Doctrine, php, Zend, zend framework