Remove Entity/Document/CouchDocument auto-detection

[beberlei]

The auto detection and differentiation between Entity/Document/CouchDocument folders is really a pain.

The FOS Bundles went to an ugly MappedSuperClass + Extend pattern to work around this.

In general Doctrine is a DataMapper, because its supposed to be persistence ignorant. All the classes can be in any folder.

Idea:

• AutoMapping points to Bundle directory, not to subdirectories anymore. That means Entities can be in any folder of the bundle.
• DoctrineBundle (Bridge) provides a way to avoid the same classes to be mapped by multiple persistence mappers, so that FOSBundle style distribution of mappings for all bundles is still possible.

[henrikbjorn]

Still waiting on that blog post :) Until another best pratice is determained this is still the best solution imo.

[lsmith77]

i would be happy if we can improve the current situation. in order to handle clashes better, we might also want to support black listing and now just white listing when the user has to manually decide which Bundles use what manager. but we also need to ensure things stay easy to config even for Bundles that provide models for different managers that the user wants to use in the same app

[dbu]

note that we since then have a compiler pass helper for bundles that want to support multiple doctrine variants. auto-detection maybe is just too much. http://symfony.com/doc/current/cookbook/doctrine/mapping_model_classes.html

FOSUserBundle does it like this to be compatible with older versions of DoctrineBundle
https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/DependencyInjection/Compiler/RegisterMappingsPass.php

[stof]

making auto_mapping pointing to the bundle itself can be an issue because it would mean that Doctrine will need to run annotations on the whole bundle when you ask for entity classes.
and if you have a bundle supporting both the MongoDB ODM and the ORM, and they are both enabled in the project, you will still want to map the bundle for only one of them generally (the one configured to be used by the bundle). The autodetection would cause some issues in such case.

The second part is indeed covered by the new compiler passes

[ostrolucky]

As far as I see logic of this is in symfony doctrine bridge, so if this is important, this issue should be raised there. And as far as we see, this didn't gaing much traction and issue itself is confusing - title talks about different things than description and description proposes two different things. If comments address right thing, we agree with @stof and @dbu opinion that making automapping scan whole bundle dir by default might be too much. Feel free to reopen issue with more concrete proposal.