Doctrine vs. Propel in symfony…

When we first moved to symfony, my only major concern was Propel. I was pushing to move to Rails, but we gave symfony a shot and ended up absolutely loving it. The two best features of symfony are the plugin architecture and how configurable it is. The only thing we could not live with was Propel. It could not provide the functionality+performance we needed out of our database. Some of the common features like calculated columns, aggregate functions with grouping, etc. are not supported in Propel. Although, a enhancement ticket exists in trac for Propel 2.0.

But we didn’t give up on symfony yet, the plugin architecture and Doctrine came together to solve our problems. Since my issues with Propel I have switched to the Doctrine ORM that is implemented by the sfDoctrinePlugin. Supposedly, Doctrine is to be the main ORM for symfony in version 1.1, so do yourself a favor and get a head start by switching to Doctrine now.

Comments {View Comments}
  • You do have to define the relationships that exist on a model. If you are using yaml schema files you must only define the relationship on the side where the local foreign key exists. The yaml schema file is parsed and used to generate complete Doctrine_Record definitions. If you manually write your Doctrine_Record you must explicitly define both ends of the relationship. In a future release yaml schema files will automatically create relationships by looking at the names of columns, but currently it does not do it.

    The reason why propel is able to do this is because Propel generates code for your models, so the overhead for generating and recognizing these relationships is irrelevant. Doctrine is an abstract implementation and you simple write "definitions" of your models which extend Doctrine_Record and everything is initialized on the fly. This means no duplicated code for each model. The overhead to magically determine relationships from the names of columns is unnecessary so we did not implement that feature and ask that you define relationships explicitly.
  • I am currently developing the architecture big web application on symphony and the "propel or doctrine" issue is still unresolved. i have just started out with them, but from what i see, i think you don't need to explicitly define relationships between different entities in the schema in propel as long as the primary keys and foreign keys follow the naming convention.. but i don't see this in doctrine. correct me if i am wrong :-)
  • I'm starting a project right now, and for me it just makes a lot of sense to use Doctrine. I have a great latitude of control over the project too, so spending time to learn how Doctrine works and the sfDoctrinePlugin in order to make enhancements will be nice.

    I'll probably still use Propel for smaller projects that require a quick turn around. Glad to hear about the SoC thing, that's great news.
  • I agree with everything you said, but if you shouldn't use doctrine and you shouldn't use propel, what do you use? Doctrine is by far the best ORM option out there for PHP. It is for sure an investment to go with Doctrine, but that is how open source software works. Without people adopting it and taking a chance when it is alpha/beta, their would be no open source software. The project is growing and many people have began using Doctrine with and without symfony. Also, another plus is that the project was picked up by the Google Summer of Code, so for the entire summer, google is funding the lead developer to work explicitly on Doctrine. He starts May 10th so when they happens you should really begin to see Doctrine make leaps and bounds towards a stable 1.0 version.
  • Hello Jonathan,

    I've tried Doctrine several times now, with and without symfony. I actually don't like it, it's still to unstable. Too many features are under heavy development and you cannot say "this will work tomorrow, after our next `svn update`". I wouldn't recommend yet to switch to Doctrine, but I wouldn't recommend to use Propel at all.

    Sadly, there's no _very good_ PHP O/RM tool available right now.
blog comments powered by Disqus