PHP ORMs: Doctrine vs. Propel [closed]

Question

I'm starting a new project with symfony which is readily integrated with Doctrine and Propel, but I of course need to make a choice.... I was wondering if more experienced people out there have general pros and/or cons for going with either of these two?

Lugansk

Answer 1

I'd go with Doctrine. It seems to me that it is a much more active project and being the default ORM for symfony it is better supported (even though officially the ORMs are considered equal).

Furthermore I better like the way you work with queries (DQL instead of Criteria):

<?php
// Propel
$c = new Criteria();
$c->add(ExamplePeer::ID, 20);
$items = ExamplePeer::doSelectJoinFoobar($c);

// Doctrine
$items = Doctrine_Query::create()
       ->from('Example e')
       ->leftJoin('e.Foobar')
       ->where('e.id = ?', 20)
       ->execute();
?>

(Doctrine's implementation is much more intuitive to me).

Also, I really prefer the way you manage relations in Doctrine.

I think this page from the Doctrine documentation is worth a read: http://www.doctrine-project.org/documentation/manual/1_2/en/introduction:doctrine-explained

To sum up: If I were starting a new project or had to choose between learning Doctrine and Propel I'd go for Doctrine any day.

Idiomorphic

In Propel 1.5, this query can also be written as Example_Query::create()->joinWith('FooBar')->filterId(20)->find() (or findPK(20) after the joinWith if Id is your primary key). As you can see, it takes the nice syntax from Doctrine, and adds a bit more. The release is planned for the end of Q1 2010, but you can test it now in your Symfony projects. – Ethiop

Nice input, I didn't know that :-) – Idiomorphic

doctrine implementation seems much more complex to me. Get Entity manage get repository... this and that – Hydrotaxis

doctrine is over complicating things... just notorm is the way to go – Finnish

Answer 2

I am biased, since I help a little bit on the next release of Propel, but you must consider that Propel was indeed the first ORM available, then lagged a bit when Doctrine got created, but now has active development again. Symfony 1.3/1.4 comes with Propel 1.4, where most comparisons stop at Propel 1.3. Also, the next release of Propel (1.5) will contain a lot of improvements, especially in the creation of you Criteria (resulting in less code for you to write).

I like Propel because it seems to be less complex than Doctrine: most code is in the few generated classes, whereas Doctrine has split up the functionality in lots of classes. I like to have a good understanding of the libraries I am using (not too much "magic"), but of course, I have more experience with Propel, so maybe Doctrine is not so complicated behind the scenes. Some say Propel is faster, but you should check this for yourself, and consider whether this outweighs other differences.

Maybe you should also consider the availability of Symfony plugins for the different frameworks. I believe Propel has an advantage here, but I don't know how many of the listed plugins are still up-to-date with the latest version of Symfony.

Ethiop

The new query improvements in Propel 1.5 are really nice indeed. – Lugansk

Answer 3

It comes down to personal preference. I use Propel because (among other things) I like the fact that everything has its own concrete getter & setter method. In Doctrine, this is not the case.

Propel:

$person->setName('Derek');
echo $person->getName();

Doctrine:

$person->name = 'Derek';
echo $person->name;

The reason I like having getters & setters is that I can put all kinds of logic in them, if I need to. But that's just my personal preference.

I should also add that although Propel was slow-moving in the past, it is now under active development again. It has released several new versions in the past few months. The most recent version of Propel includes a "fluent query interface" similar to Doctrine's, so you don't have to use Criteria anymore if you don't want to.

Os

in Doctrine you can override setters and getters for each property and also have custom logic (see doctrine-project.org/documentation/manual/1_2/en/… - search for ATTR_AUTO_ACCESSOR_OVERRIDE to get to the relevant section) – Signal

That looks ok, but you still set the property by calling: $x->propname = 'abc'; This is problematic because it doesn't appear to support passing multiple parameters. – Os

Answer 4

It should be noted Doctrine 2 is currently in development released [ed] and functions almost completely different from the current stable version of Doctrine 1. It relies on the Data Mapper pattern instead of Active Record, and uses an 'entity manager' to handle persistence logic. When released it will bear closer resemblance to Java's Hibernate (Doctrine 1 is more like Rails' ActiveRecord).

I've been developing with the alpha release of Doctrine 2, and must say it is heads and shoulders above Doctrine 1 (just my opinion, and I've never used Propel). Chances are good that the Doctrine community will move toward it when it's released.

I would encourage you to check out Doctrine, but if you prefer the Active Record style that Propel and Doctrine use now, you might want to just stick with Propel.

Daube

A stable version of Doctrine 2 was recently released. doctrine-project.org/blog/doctrine2-released – Ladysmith

Answer 5

The two references are somewhat outdated so you nevertheless cover some generalities, basically you'd have to evaluate your experience with the framework as such, a major drawback to doctrine is the inability to have an IDE that lets you auto-code in that propel is a winner, learning curves propel and doctrine are very different, it is easier to propel, if your project will need to manage complex data model uses doctrine, if you want to work quickly with an ORM which is best documented and find more support in Propel Internet uses, is much more mature and I believe that most used.

http://propel.posterous.com/propel-141-is-out

Cecilycecity

In the symfony world it seems that Doctrine is definately the most used - especially for newer projects. There are of course a lot of sf 1.0 projects that still use Propel because Doctrine wasn't available for symfony until 1.1. – Idiomorphic

Answer 6

I'd suggest to use propel 1.6 which is better for IDE's autocomplete function.

Guthry

-1 Autocompletion of an IDE shouldn't be the reason of a technical choice – Calli

@ClementHerreman I agree it shouldn't be the criteria, but I believe how productive one can be with a particular technology should certainly be a reason for choosing it. And with all-due respect I therefore disagree with your downvote... regardless of if you agree with the answer, it's not "wrong" (or is it?), and it is of some use (unless it's wrong, in which case, you should state this). – Nonfeasance

IMO if your productivity is more improved by autocompletion instead of software quality, intuitivity and consistency, then something weird is happening. See codinghorror.com/blog/2009/01/…. But you're right, at some point this answer isn't wrong, just not good enough, maybe even not good. – Calli

@ClementHerreman, if isn't helpful don't use it anymore ;), +1 – Lakin

Are there any up to date responses to this? This is way out of date. – Furbelow

I don't agree with Clement. Regarding development the IDE is the most important factor. – Jemena

When you are working with a project that has over 600 tables auto-completion of an IDE is a reason to make a technical choice. The technical choice being in the range of 10's to 100's of thousands of dollars on time wasted referencing documentation or raw schema. – Slice

Answer 7

I'm not a user of PHP 5 non-framework ORM, but here's some good comparison posts (in case you haven't seen them yet):

http://codeutopia.net/blog/2009/05/16/doctrine-vs-propel-2009-update/

http://trac.symfony-project.org/wiki/ComparingPropelAndDoctrine

Both conlusion favorite towards Doctrine as a newer generation of ORM for Symfony.

Thermic

For the record, this comparison is totally outdated - current version of Propel does use PDO, does use support many-to-many relationships, and has great documentation. Also worth considering: some of us prefer the verbose criteria-builder query-style over proprietary query languages like DQL - it has IDE support, and it's a class, so you can extend it. I'm still trying to choose, but I see a lot of plus'es for Propel over Doctrine, if you don't mind static code-generation and can see the advantages of "real" PHP code as opposed to proprietary query-language, which is just strings to an IDE. – Zildjian

Answer 8

After using both of them for a number of years I prefer Propel 2 to Doctrine simply based on how you construct your query logic. Doctrine is as in depth as it can get and managing many aspects of it match that level of depth. Propel I feel has a more fluid and object driven way of building and managing the query interactions.

For me this led to less code in the model and more structures around how logic can/will be processed. This resulted in just building out many interactions as common functionality. (After all 90% of what you will do with a database is just going to be some degree of crud operation.)

In the end, both are powerful, manageable and will get the job done. My personal projects and interest use Propel ORM 2 and future projects, if still written in PHP will go that route.

I've been using both on a daily basis for the past 3-4 years.

Slice

Answer 9

I'd suggest using DbFinder Plugin. This is actually a very powerful plugin that supports both, and is quite a nice powerful. I actually like using it better than either.

Marentic

@Mike: thanks, didn't know about the plugin but seems it only supports up to Sf1.2. I ended up going with Doctrine in the end, feels like it was the right choice, although writing direct SQL is needed for the more complex stuff. – Lugansk

Answer 10

If I'm not wrong, both ORMs use XML-based schema, and creating these schema definition is pretty cumbersome. If you need a PHP-based simple schema with fluent style. You may try LazyRecord https://github.com/c9s/LazyRecord it supports automatic migration and upgrade/downgrade script generators. And all the class files are generated statically without runtime cost.

Gregorygregrory