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.
Thumbs up!
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!
Yep., Thumbs up!
Good decision!
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,
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.
PROPEL IS EASIERRRRRRRRRR
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)
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...
Thank you, thank you, thank you. Sometimes a clear sense of direction is worth the price of not pleasing everyone.
can we integrate adodb or PEAR db into symfony somehow?
@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
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.
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.
Well, DbFinderPlugin can help me to avoid some disagreements...
Thumbs up! [3]
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.
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??
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...
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
@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.
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.
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.
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.
That benchmark for lightorm vs proper vs doctrine is for doctrine version 0.10.2.
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.
Yeahhh great news. big thanks
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.
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.