The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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.

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).

I opted for a tool with a build phase as a workaround, and chose Torque as the basis for Propel.

What scope is there for a caching generated code? In the same way that Smarty "compiles" templates, could we we write meta-PHP which generates code to do the DB access? Could take up the slack from trying to redo the DB reflection which would have to be redone pre request...

What scope is there for a caching generated code? In the same way that Smarty "compiles" templates, could we we write meta-PHP which generates code to do the DB access? Could take up the slack from trying to redo the DB reflection which would have to be redone pre request...

I guess what I meant by "scope" was that it felt like an object persistence model that required a caching framework was beginning to do things that it shouldn't be doing. Of course that's really just personal taste.

Propel actually does use code generation (kinda analogous to Smarty) to create Map classes that contain the metadata -- so that it can be queried without relying on a database round-trip. So there are ways to speed up the metadata lookups, but I still think performance is gonna be an issue if you need to discover an objects relationships every time you use it in a query. The pre-built solution that Propel takes is certainly far less flexible than Hibernate, but this was an intentional decision made for performance sake (and I don't think yet that it was a bad decision).

Originally Posted by DougBTX

Can PHP take advantage of things like lighttpd that Ruby can?

I don't know what that is, but I assume not. Recently people on the Propel list are talking a lot about Ruby on Rails (which does look cool) and asking about live metadata lookups. I figured there must be something Ruby can do involving state that isn't a readily-available option for PHP users.

I don't know what that is, but I assume not. Recently people on the Propel list are talking a lot about Ruby on Rails (which does look cool) and asking about live metadata lookups. I figured there must be something Ruby can do involving state that isn't a readily-available option for PHP users.

With plain CGI, Ruby acts much like stateless PHP - and Rails is PITA slow. When running on FastCGI on lighttpd (a web server, does the same job as Apache) or even mod_ruby on Apache, it is fast. I don't think that speed up has anything language specific.

The guy who wrote most of Rails is ex-PHP, so prehaps he saw things he wanted to do but couldn't with PHP. That's just speculation though.

quickly start leaving the scope of "object persistence layer".

Yea, it seems to get closer to a "PHP persistence layer" when the "object persistence layer" starts getting too big to persist itself!

Alternate ORM with GUI editor

Openbiz (http://phpopenbiz.org) framework has complete ORM and object persistancy. It also provides Eclipse plugin to make the ORM config very easy. Take a look at it. It's easier to get hands on it than Hibernate