Hacker News new | past | comments | ask | show | jobs | submit login

I'm not the OP but almost any PHP project these days has me reaching for Symfony 2[0] or her little brother Silex[1] paired with Doctrine 2[2].

[0]. http://symfony.com/ [1]. http://silex.sensiolabs.org/ [2]. http://www.doctrine-project.org/




Symfony is nice, Zend 2 is going to fix everything from ZF1 and is worth keeping an eye on as well.

I've dabbled in Doctrine before, but the memory usage looked a little too high for the convenience it offered.


Out of curiosity what are you doing in PHP where memory usage is an issue? PHP's standard life cycle, while having numerous disadvantages, avoids a lot of problems with memory usage.

It's a rather different beat, but you might checkout Propel (http://propelorm.org) for a different take on a PHP ORM. It has a static build phase unlike Doctrine which turns some people off, but if you can get past that it's a rather nice ORM.


If you think that your project is going to grow into a substantial code base, I would NOT recommend Propel.

A lot about their active record implementation violates POLA with various gotchas and code generation gets tedious and unwieldy with models that contain many fields or relations.


Interesting, I've been using Propel for so long I've probably internalized all the gotchas. What in particular caught you off guard?


My favourite is probably:

Say you want to add a product to an existing order in the database...

$orderProduct = new OrderProduct(); $order = OrderPeer::retrieveByPK(1);

$order->addOrderProduct($orderProduct);

Now, if ANYWHERE after this point in the code, something calls $order->getOrderProducts() before you call $order->save() (like a validation routine or something) you will lose that new OrderProduct and it will not be persisted.

It's bit me more than once, especially as you start to spread code around that depends on traversing the relationships - can be a very tricky bug to spot.


Propel's implementation of related collections definitely could use some improvement. In your example, you wouldn't necessarily lose your new object, it just wouldn't be persisted through a call to the parent order to save. My general habit is to call save on a newly created object directly, and as soon as possible. Regardless, I definitely agree this is one (and there are some other points) where Propel definitely has rough edges.


With this project in particular, each time someone hits the main page there are 6 php scripts executed in parallel. I was hitting some limits with my VPS during those spikes.


Yes with some complicated work patterns, Doctrine becomes memory and cpu/time hungry. I've been struggling with doctrine issues with our customers event portal. Most of the time we have to turn back into array based hydration. Even then time/cpu intensiveness is still there.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: