PHP ORMs: Doctrine vs. Propel

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?

Thanks a lot.

EDIT: Thanks for the all the responses, useful stuff. There's no truly correct answer to this question so I'll just mark as approved the one that got the most popular up-votes.

Guys, are there any updated responses? Seeing that this way out of date — Qiniso, Jan 23 '15 at 17:23

score 78 · Accepted Answer · answered Jan 14 '10 at 06:51

78

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.

answered Jan 14 '10 at 06:51

phidah

5,794
6
37
58

42

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. – Jan Fabry Jan 15 '10 at 07:24
Nice input, I didn't know that :-) – phidah Jan 15 '10 at 10:10
9

doctrine implementation seems much more complex to me. Get Entity manage get repository... this and that – SoWhat May 09 '13 at 11:43
1

doctrine is over complicating things... just notorm is the way to go – Geomorillo Oct 20 '16 at 14:48

score 39 · Answer 2 · answered Jan 14 '10 at 09:23

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.

The new query improvements in Propel 1.5 are really nice indeed. — Tom, Jan 14 '10 at 21:08

score 23 · Answer 3 · answered Jan 14 '10 at 19:59

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.

in Doctrine you can override setters and getters for each property and also have custom logic (see http://www.doctrine-project.org/documentation/manual/1_2/en/introduction-to-models - search for ATTR_AUTO_ACCESSOR_OVERRIDE to get to the relevant section) — Marek Karbarz, Jan 20 '10 at 02:21
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. — lo_fye, Jan 20 '10 at 17:11

score 20 · Answer 4 · edited Jun 01 '11 at 08:48

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.

A stable version of Doctrine 2 was recently released. http://www.doctrine-project.org/blog/doctrine2-released — Trevor Allred, Jan 04 '11 at 02:35

petkopara · Answer 5 · 2016-02-28T09:36:10.793

5

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

edited Feb 28 '16 at 09:36

answered Sep 26 '12 at 13:49

petkopara

189
3
9

28

-1 Autocompletion of an IDE shouldn't be the reason of a technical choice – Clement Herreman Sep 26 '12 at 13:54
14

@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). – Sepster Sep 26 '12 at 14:00
2

IMO if your productivity is more improved by autocompletion instead of software quality, intuitivity and consistency, then something weird is happening. See http://www.codinghorror.com/blog/2009/01/the-sad-tragedy-of-micro-optimization-theater.html. But you're right, at some point this answer isn't **wrong**, just not good enough, maybe even not good. – Clement Herreman Sep 26 '12 at 14:05
1

@ClementHerreman, if isn't helpful don't use it anymore ;), +1 – amd Jan 21 '15 at 12:28
Are there any up to date responses to this? This is way out of date. – Qiniso May 07 '15 at 19:25
I don't agree with Clement. Regarding development the IDE is the most important factor. – Crouching Kitten Aug 21 '17 at 12:09
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. – Ryan Rentfro Aug 05 '18 at 20:38

score 5 · Answer 6 · answered Jan 14 '10 at 06:35

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

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. — phidah, Jan 14 '10 at 06:58

Trav L · Answer 7 · 2010-01-14T06:18:48.423

2

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.

edited Jan 14 '10 at 06:18

answered Jan 14 '10 at 06:08

Trav L

14,732
6
30
39

1

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. – mindplay.dk Nov 08 '12 at 14:49

score 2 · Answer 8 · answered Aug 05 '18 at 20:35

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.

score 1 · Answer 9 · answered Apr 07 '10 at 01:51

1

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.

answered Apr 07 '10 at 01:51

Mike Crowe

2,203
3
22
37

@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. – Tom Apr 07 '10 at 02:43

c9s · Answer 10 · 2016-06-20T03:55:20.860

-2

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.

edited Jun 20 '16 at 03:55

answered Jun 18 '16 at 16:03

c9s

1,888
19
15

PHP ORMs: Doctrine vs. Propel

10 Answers10

Linked