New in symfony 1.3: What's up with Propel and Doctrine?
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.
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
Comments are closed.
To ensure that comments stay relevant, they are closed for old posts.
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,
++ 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.
I'm sorry, but i don't really like Doctrine, especially for the DQL thing (and the generated queries are really ugly IMHO)
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...
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
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.
In the future we have change again? why DBfinder are not a solution? or is impossible have both orm at same project? cheers
@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.
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.
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.
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.
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.