Archives


Master Symfony2 fundamentals

Be trained by SensioLabs experts (2 to 6 day sessions -- French or English).
trainings.sensiolabs.com

Discover the SensioLabs Support

Access to the SensioLabs Competency Center for an exclusive and tailor-made support on Symfony
sensiolabs.com

Fabien Potencier
New in symfony 1.3: What's up with Propel and Doctrine?
by Fabien Potencier – June 11, 2009 – 29 comments

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.

Comments RSS

  • gravatar
    #1 Damjan said on the 2009/06/11 at 09:48
    Thumbs up!
  • gravatar
    #2 Scott Meves said on the 2009/06/11 at 10:04
    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!
  • gravatar
    #3 Björn Ahlers said on the 2009/06/11 at 10:31
    Yep., Thumbs up!
  • gravatar
    #4 Fabian Spillner said on the 2009/06/11 at 11:17
    Good decision!
  • gravatar
    #5 Bob said on the 2009/06/11 at 11:31
    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,
  • gravatar
    #6 Frank said on the 2009/06/11 at 11:59
    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.
  • gravatar
    #7 bob said on the 2009/06/11 at 12:07
    PROPEL IS EASIERRRRRRRRRR
  • gravatar
    #8 lloyd27 said on the 2009/06/11 at 12:35
    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)
  • gravatar
    #9 David said on the 2009/06/11 at 13:05
    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...
  • gravatar
    #10 Tom Boutell said on the 2009/06/11 at 13:58
    Thank you, thank you, thank you. Sometimes a clear sense of direction is worth the price of not pleasing everyone.
  • gravatar
    #11 salman said on the 2009/06/11 at 14:00
    can we integrate adodb or PEAR db into symfony somehow?
  • gravatar
    #12 Jonathan H. Wage said on the 2009/06/11 at 14:38
    @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
  • gravatar
    #13 Dennis Verspuij said on the 2009/06/11 at 14:59
    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.
  • gravatar
    #14 Jonathan O. Nieto (ice_j7) said on the 2009/06/11 at 19:21
    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.
  • gravatar
    #15 dlnieves said on the 2009/06/11 at 20:27
    Well, DbFinderPlugin can help me to avoid some disagreements...
  • gravatar
    #16 Rui Silva said on the 2009/06/11 at 23:13
    Thumbs up! [3]
  • gravatar
    #17 lynx said on the 2009/06/12 at 00:55
    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.
  • gravatar
    #18 saganxis said on the 2009/06/12 at 01:17
    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??
  • gravatar
    #19 vitriolix said on the 2009/06/12 at 01:25
    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...
  • gravatar
    #20 puentesdiaz said on the 2009/06/12 at 06:10
    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
  • gravatar
    #21 Fabien said on the 2009/06/12 at 07:55
    @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.
  • gravatar
    #22 Fabian Lange said on the 2009/06/12 at 07:59
    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.
  • gravatar
    #23 lynx said on the 2009/06/12 at 16:39
    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.
  • gravatar
    #24 Rob Jensen said on the 2009/06/14 at 05:16
    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.
  • gravatar
    #25 Nikolai Bochev said on the 2009/06/14 at 11:24
    That benchmark for lightorm vs proper vs doctrine is for doctrine version 0.10.2.
  • gravatar
    #26 hichem said on the 2009/06/17 at 14:51
    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.
  • gravatar
    #27 altrano said on the 2009/06/17 at 22:32
    Yeahhh great news. big thanks
  • gravatar
    #28 Johan said on the 2009/06/19 at 07:04
    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.
  • gravatar
    #29 Ernesto said on the 2009/06/22 at 22:18
    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.