Quote Originally Posted by MiiJaySung
All in all Propel becomes problematic when you have complex relationships where your in memory objects don't tend to be a direct reflection of your tables. Propel's criteria system also is a little unflexible in places too. I can't do LEFT JOINS, and subqueries with it. Also the Basepeer class that compiles the criteria to code also can't handle things where you have column aliases when you deal with aggregate functions. This is because it tries to resolve the aliased column in it's DB table / column maps.

Looking at flaws in features in other ORM tools might be a good way to build up a specification to work, along with provide some usage cases.
I agree -- this is the main problem with Propel. I'm very curious to see what you guys come up with. Note that before starting Propel I actually spent a long time considering a port of Hibernate to PHP5. I finally decided that Hibernate just didn't fit into the PHP stateless model, but you may find a workaround. I opted for a tool with a build phase as a workaround, and chose Torque as the basis for Propel.

Here's some history: http://propel.phpdb.org/wiki/index.php?node=41

Note that the reason why Propel handles things like complex SQL needs and many-to-many relationships so poorly is primarily due to the fact that it does not use runtime metadata lookups (or very minimal). Propel is fairly optimized code and while I think performance is good, it tends to push the limits of PHP Not everyone thinks Propel is fast enough for their large-scale applications. I can only imagine that if you start parsing HQL at runtime and performing metadata queries you are going to have some serious performance stuff to deal with. ... which I assume (without having read this whole thread) will lead to caching & other technologies that quickly start leaving the scope of "object persistence layer".

Anyway, I'm very keen to see the outcome of this discussion. In my mind it would also be great to find a way to work together (e.g. Propel 2 is going to have some more hibernate-like features in terms of a looser mapping to SQL tables).

Cheers,
Hans