New in symfony 1.3: What's up with Propel and Doctrine?

June 11, 2009 · Published by Avatar of Fabien Potencier Fabien Potencier

Before we began working on symfony 1.3, we asked the community about their priorities for the framework.

We had a lot of suggestions, and some of them were contradictory. As of today, the second and fourth most voted suggestions are: "make Doctrine the default ORM" and "do not make Doctrine the default ORM". How can we make everybody happy?

Thanks to the new installer feature of the generate:project task, symfony 1.3 is able to create a project for Doctrine or Propel very easily.

But we still need a default ORM. That was not my opinion some months ago, but after some great discussions with members of the community, I changed my mind. We don't want to bother new users with a question about the ORM they want to use. How a newcomer can make a choice between Propel and Doctrine? It is just not possible. We cannot ask him to read all the documentation just to make a choice. It does not make any sense. As Doctrine is the future of symfony, we decided to make it the default choice when creating a new project:

$ php /path/to/symfony generate:project foobar

But if you still want to use Propel, that's not a problem, just add a --orm option:

$ php /path/to/symfony generate:project foobar --orm=Propel

The implementation is dead-easy, and you will now enjoy a Propel-free project when using Doctrine, and of course the other way around when working with Propel.

To sum up, symfony 1.3 support both Propel and Doctrine equally, with a preference towards Doctrine if you start a new project today.

Published in #Living on the edge

Help the Symfony project!

As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.

Comments

Avatar of Damjan
Damjan said on Jun 11, 2009
Thumbs up!
Avatar of Scott Meves
Scott Meves said on Jun 11, 2009
I think it's the right call. I know and love propel very much, but I agree that doctrine is the future and will serve the symfony community very well!
Avatar of Björn Ahlers
Björn Ahlers said on Jun 11, 2009
Yep., Thumbs up!
Avatar of Fabian Spillner
Fabian Spillner said on Jun 11, 2009
Good decision!
Avatar of Bob
Bob said on Jun 11, 2009
That's a great idea!

But what about some projects where we don't need any ORM (I'm working on one). One will be used by default...

A "--no-orm" option could be the answer!

Regards,
Avatar of Frank
Frank said on Jun 11, 2009
Great! You solved the problem in a perfect way!
++ for Bobs suggestion. One of our projects do not use an ORM, too. Our model is served by another SOA application and we do not use Propel or Doctrine here at all.
Avatar of bob
bob said on Jun 11, 2009
PROPEL IS EASIERRRRRRRRRR
Avatar of lloyd27
lloyd27 said on Jun 11, 2009
I agree with Bob, once you get how criteria works propel is easier (and much cleaner) in my opinion.

I'm sorry, but i don't really like Doctrine, especially for the DQL thing (and the generated queries are really ugly IMHO)
Avatar of David
David said on Jun 11, 2009
I like the decision of making Doctrine the default ORM because it is the one I use.

But I have a question: if the future of symfony is doctrine, then, why not discuss here those little ugly things about doctrine? (lack of features in dql, ugly queries, inefficient way of doing things...)

In many occasions I have been forced to write direct PDO queries because Doctrine eats many MB of memory, and because of its low speed...
Avatar of Tom Boutell
Tom Boutell said on Jun 11, 2009
Thank you, thank you, thank you. Sometimes a clear sense of direction is worth the price of not pleasing everyone.
Avatar of salman
salman said on Jun 11, 2009
can we integrate adodb or PEAR db into symfony somehow?
Avatar of Jonathan H. Wage
Jonathan H. Wage said on Jun 11, 2009
@David I would love to discuss those things. We are always working on these things during the Doctrine development. Doctrine mailing list, doctrine trac, irc, etc. You can join us and help, it would be greatly appreciated.

Most of these things have been or will be addressed in Doctrine 2.0 and we can possibly make smaller changed in Doctrine 1.x to improve things until people are able to upgrade to Doctrine 2
Avatar of Dennis Verspuij
Dennis Verspuij said on Jun 11, 2009
Good work.
Btw, I think it would be neat to remove sfPropelPlugin from the default $plugins array in sfProjectConfiguration so by default there are no plugins enabled, only those explicitely added by the installer and/or developer in its custom ProjectConfiguration class.
Avatar of Jonathan O. Nieto (ice_j7)
Jonathan O. Nieto (ice_j7) said on Jun 11, 2009
Even if Propel is easier (I also started symfony with propel in 1.0 version) and nice by the way, Doctrine with a steeper learning curve has much more to offer. I like both, but when I met Doctrine and studied it I had to accept this fact.
Avatar of dlnieves
dlnieves said on Jun 11, 2009
Well, DbFinderPlugin can help me to avoid some disagreements...
Avatar of Rui Silva
Rui Silva said on Jun 11, 2009
Thumbs up! [3]
Avatar of lynx
lynx said on Jun 12, 2009
As someone who already knows Propel and is about to start another project I have a question. Do you see a time in the future that Propel won't be an option any more? Such as version 1.4 of symfony? Knowing this going forward will make decisions easier on if we should contiune the use of Propel because we like/know it or we should take the time out to learn Doctrine because it is the "future" and soon may be our only option leaving all our other projects behind. From what I gather it isn't easy to switch ORM's once you have finished a project.
Avatar of saganxis
saganxis said on Jun 12, 2009
Good decision to choose one ORM. But one question. What about documentation?Is the idea to keep duplicating the symfony documentation? I think this kind of things make hardest the translators job. We have sf 1.0, 1.1, 1.2, 1.3 and besides propel and doctrine. That's too much documentation for translate(even if there are small changes between them).What do you think about??
Avatar of vitriolix
vitriolix said on Jun 12, 2009
Good call. While I use Propel in both my big Sf projects, I support this move. Giving preference to one is controversial and a hard call, but having the community split down the middle using 2 ORM's is just not tenable, it dilutes one of the biggest gains in adopting a framework: a pile of useful plugins and addons available to you. I hope the community follows suit Doctrine now. I'm going to go add "port to doctrine" to my todo lits now...
Avatar of puentesdiaz
puentesdiaz said on Jun 12, 2009
well, i think that new users are happy. I see doctrine veary well, but what happend with a lot a plugins, the plugins that use propel??
In the future we have change again? why DBfinder are not a solution? or is impossible have both orm at same project? cheers
Avatar of Fabien
Fabien said on Jun 12, 2009
@lynx: we won't remove Propel support from the 1.x branch. We are committed to support Propel for ALL versions of symfony 1.x. For Symfony 2, the core team will ONLY support Doctrine. It does not mean that you won't be able to use Propel, it just means that we will only support Doctrine.

@saganxis: You are totally right. Supporting two ORMs means supporting two code bases, two set of documentation, two set of transalations, and some more. That's also something that split the community. But, as I said, for the 1.x branch, we will continue to support both ORMs for the code and the documentation.
Avatar of Fabian Lange
Fabian Lange said on Jun 12, 2009
As some people have asked about the future of Propel in symfony, I think it is more important to have a look at the future of Propel itself.
Check the repository changes on Propel in the last 3 months:
http://propel.phpdb.org/trac/timeline?from=06%2F12%2F09&daysback=90&changeset=on&update=Update

While we do not plan to stop continuing supporting propel for symfony 1.x, we have to admit that Doctrine has the better drive.

Propel/Doctrine related documentation should not be that issue, because they are combined in a single file.

Plugins already have been an issue. Plugins decay very fast, so plugin authors need to update very often. And they need to make a choice what to support. I don't see a big problem in some plugins available for Propel/Doctrine only. But what I can see is the vendor lock in for the user of a plugin. That is the risk you always take when making a decision to go forward with a certain technology. And the choice of an ORM is a big one.
However I feel that there will be ports of popular propel Plugins for Doctrine pretty soon. Or DbFinder based plugins.
Avatar of lynx
lynx said on Jun 12, 2009
Thank you for the info. I now have to think how I want to take my next project. If I use the Doctrine ORM I may find the plugins I need not available and I have a learning curve so it will delay the project. On the other hand if I stick with Propel for the next project I would be limiting my upgrade path for that project. Not that any of this is a bad thing. I think it is a great decision to have one default ORM layer.
Avatar of Rob Jensen
Rob Jensen said on Jun 14, 2009
My initial reaction to this was fantastic, and I've started to move a project from propel to doctrine. I've since changed my mind after I found out just how bad the performance of Doctrine is, my page load went from 50ms to over 300ms doing a simple join with doctrine. That's supported by these findings here: http://phplightorm.wiki.sourceforge.net/LightOrm+vs+Propel+vs+Doctrine+benchmark

I totally agree that it's important to select one ORM going forward for symfony how ever Doctrine does not seem to have the performance.
Avatar of Nikolai Bochev
Nikolai Bochev said on Jun 14, 2009
That benchmark for lightorm vs proper vs doctrine is for doctrine version 0.10.2.
Avatar of hichem
hichem said on Jun 17, 2009
good decision !
i've seen doctrine and propel and i prefer propel because it's safer and faster and EASIER than doctrine. To be honnest, i don't know why you've decided to make Doctrine as the default ORM.
Avatar of altrano
altrano said on Jun 17, 2009
Yeahhh great news. big thanks
Avatar of Johan
Johan said on Jun 19, 2009
I've been using propel for two years, and reviewing Doctrine, as I considered to move over.
For big projects where you cannot have all table and column names in your head code completion (which works with propel, NOT doctrine) reduces dev. time greatly. Additionally the way the queries are built up in Propel reduces possibilities for errors. Learning the criteria's is definitely worth it, and not very hard.
I'd be interested to know that made the Symfony team go for Doctrine - it is not at all obvious.
Other than that - Symfony is the greatest php framework ever! It's a pure joy to work with it.
Avatar of Ernesto
Ernesto said on Jun 22, 2009
Propel is perfect for my, clear, intituitive. Now i needed do some changes to get the model of some tables and not the all tables in my database, because some tables are create dinamically a I can change de PROPEL kernel whitout problems. If any people need do write to email: ernestos@uci.cu and i send de changes.

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.