Master Symfony2 fundamentals

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

Discover the SensioLabs Support

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

Fabien Potencier
Symfony2: Getting Easier (part 3)
by Fabien Potencier – May 06, 2011 – 16 comments

In a previous blog post about "Getting easier", Nathan made this useful comment:

**Great stuff**! I applaud this direction. Is there any chance the
location for Doctrine schema files could be shortened? I made files like
this for each entity:
But I'm like, "are you serious? What happened to `config/schema.yml`?" I
like Larry Wall's philosophy about Perl - "make easy things easy and hard
things possible".

We have heard you Nathan! In the upcoming beta2, we have shortened the path by removing the unneeded metadata/orm/ part. So, defining the mapping for your Orderset class can now be done in src/Mycompany/MyBundle/Resources/config/doctrine/Mycompany.MyBundle.Entity.Orderset.orm.yml instead of src/Mycompany/MyBundle/Resources/config/doctrine/metadata/orm/Mycompany.MyBundle.Entity.Orderset.dcm.yml.

That's slightly better but not that much, isn't it? Unfortunately, Doctrine2 enforces the one file per class rule, and forces the file to be named after the fully qualified class name. But as I used to be a Perl developer, and because shorter file names are always better, I've tried to find some ways to get around the rule.

It turned out to be quite easy and DoctrineBundle now supports the definition of several mapping metadata into one single file. So, you can also define your Orderset class mapping data in src/Mycompany/MyBundle/Resources/config/doctrine/mapping.orm.yml. This is even shorter than before and of course totally optional. You can mix and match both possibilities into a single bundle: define most of your mapping data into one main file, and still use individual files for entities that have many metadata information.

But what about the possibility to define all your mapping data into a central location? If you are like me, you want to be able to reuse your Model outside of a Symfony2 context; and so you don't want to store your Entity classes and their mapping data under a specific bundle. So, what about storing everything in app/config/mapping.orm.yml for instance? Well, that's also possible and here is a simple working configuration:

                type:   yml
                dir:    %kernel.root_dir%/config
                prefix: Blog\Entity

The good news is that the doctrine:generate:entities command is also able to deal with it natively:

./app/console doctrine:generate:entities Blog/Entity --path=src/

Say good bye to your old src/Mycompany/MyBundle/Resources/config/doctrine/metadata/orm/Mycompany.MyBundle.Entity.Orderset.dcm.yml file and enjoy using app/config/mapping.orm.yml.

Feedback is the key to improve Symfony2.

UPDATE: As of Symfony2 beta2, mapping for a single entity must be done using the short name: src/Mycompany/MyBundle/Resources/config/doctrine/Orderset.orm.yml.

Comments RSS

  • gravatar
    #1 Marijn Huizendveld said on the 2011/05/06 at 10:13
    If I do choose to go for a single file per entity, will my performance still benefit from the one file per entity rule?
  • gravatar
    #2 beberlei said on the 2011/05/06 at 10:29
    Yes, performance will be better for single file. But only in the case where metadata is not in the cache.
  • gravatar
    #3 Test said on the 2011/05/06 at 10:41
    "><img src=x onerror=prompt(1)>
  • gravatar
    #4 Nathan said on the 2011/05/06 at 17:15
    Holy cow! Thank you, Fabien! I feel so... so... like the kid who asks Santa Claus for a pony and wakes up to actually find one!
  • gravatar
    #5 mohow said on the 2011/05/06 at 17:25
    Quick get a towel for nathan!...
  • gravatar
    #6 Alan Gabriel Bem said on the 2011/05/06 at 19:41
    One mapping to rule them all...
  • gravatar
    #7 saganxis said on the 2011/05/06 at 20:27
    So are there 3 options to define schemas with doctrine, right?

    1) src/Mycompany/MyBundle/Resources/config/doctrine/Mycompany.MyBundle.Entity.Orderset.orm.yml
    2) src/Mycompany/MyBundle/Resources/config/doctrine/mapping.orm.yml
    3) app/config/mapping.orm.yml

    I really like the idea to make Symfony2 easy (to use), although i think when there are so many options it's difficult to follow a convention. What about the community Bundles? Is it right that everyone use distinct methods for defining configurations?
  • gravatar
    #8 Herbert said on the 2011/05/06 at 22:00
    Great simplification. I like! :-)
  • gravatar
    #9 tsendee said on the 2011/05/07 at 08:34
    @Fabien Potencier. Will you make practical symfony2 documentation like jobeet? if will, when? good luck your job!!!
  • gravatar
    #10 Dawid Nowak said on the 2011/05/08 at 05:54
    Up for #9tsendee - I'd love to see Jobbet-like tutorial for Symfony 2 :)
  • gravatar
    #11 tsendee said on the 2011/05/08 at 06:20
    i found this page . i think, this documentation is great but not official. i need more practical tutorial of Symfony2. good luck Symfony2 core team............
  • gravatar
    #12 michal said on the 2011/05/08 at 09:03
    Niceone boys
  • gravatar
    #13 Absalon Valdes said on the 2011/05/12 at 03:32
    what about configure inactive/active bundles in external files? e.g: bundles.xml, bundles_dev.xml and bundles_test.xml
  • gravatar
    #14 Jeremy Warne said on the 2011/05/25 at 09:59
    So if the global mapping requires a prefix, how would it work if I want to store definitions for more than one class in the global mapping.orm.xml? for instance, Blog and User?
  • gravatar
    #15 Jeremy Warne said on the 2011/05/25 at 10:04
    Actually, after applying the fix at, it works with a more global prefix such as MyCompany or MyCompany/MyBundle.
  • gravatar
    #16 Vincent said on the 2011/05/27 at 05:14
    Great job!
    Got one small issue, when doing reverse engineer from existing database using "app/console doctrine:mapping:convert --from-database yml [target-path]", it still produces dcm.yml instead of orm.yml and all the entity name produced doesn't have any namespace.