As we announced in our previous post we’ve decided to start using Doctrine instead of Propel.
The first steps in this direction are not about starting the new project though. We would like to see how simple would be to replace Propel with Doctrine in very simple project (like 2-3 simple DB tables).
It’s good that this process is already started and some steps are described in this Wiki article:
http://trac.symfony-project.org/wiki/ConvertingPropelProjectToDoctrine
But honestly not everything looks so cloudless. We were awared that Doctrine uses different schema syntax but it’s getting painful when you need to generate schema from existing DB. So if you have project with schema files described in plugins (e.g. sfGuardPlugin, etc) – you’ll have to generate new schema for Doctrine from existing DB and then slice this schema.yml (notice that Doctrine uses for it confiig/doctrine/schema.yml not confiig/schema.yml) into separate schemas for each plugin manually. Agree that if you have big project with lot of plugins this will be tricky.
So don’t forget to look into the Doctrine schema syntax before you’ll start doing that, e.g. here:
http://www.symfony-project.org/blog/2008/06/16/getting-started-with-doctrine-and-symfony-1-1
We are continuing to look into migration of existing project procedure and will keep you up-to-dated.
So far popular message for our command:
./symfony doctrine:build-all-load –no-confirmation
is
>> doctrine creating databases
>> doctrine generating model classesNo yml schema found in /www/project/cache/tmp, /www/project/config/doctrine
We have doctrine schemas described in plugins (not in /config/doctrine), but it’s strange anyway. In Propel we used to use this approach – all DB schemas were defined in separate plugins. Are we forced to add something to main doctrine/schema.yml (so far the file is empty)? I guess no but don’t see the answer yet.
3 replies on “Ok, so Doctrine.. Part 2”
The other big issue with conversion of projects from Propel to Doctrine is the number of plugins that were built in Propel and therefore can’t be used in the switch.
It’s going to be an interesting time being a symfony developer because either the plugins will need to be switched to using the dbFinderPlugin, which adds yet another layer to allow for conversion between Propel 1.2/1.3 and Doctrine, or it will need to be ported over and two different plugins be kept (here’s looking at you sfGuardPlugin/sfDoctrineGuardPlugin).
I imagine this is how the Doctrine users felt while all the plugins were being developed solely for Propel…
Absolutely agree.
I had some thoughts today and came to conclusion that there is also tactical element in switching Symfony to Doctrine by default. So I guess it’s because of Doctrine’s lead developer is Jonathan Wage (http://twitter.com/jwage). He is great symfony contributor and person related with (read “loyal to”) symfony project. So I guess at this point it’s easier for SensioLabs to coordinate and affect Doctrine development which was not possible with Propel. The similar situation happened to Swift mailer project which is now managed by Fabien Potencier (http://twitter.com/fabpot).
Main conclusion I made is – from now Doctrine will play much more important role and probably community by inertia will keep producing some Propel-oriented plugins but for long term – Propel will be moving away from Symfony scene. So that’s what we should be ready for 🙂
i think it’s good because with only one ORM symf can focus on better. and I think Doctrine is very powerful (that’s for it I left zend)
but is miss an easy tool to generate plugins! I agree we lost a lot of times