Doctrinebundle: Split bundle into dbal-bundle and orm-bundle

[alcaeus]

Currently, this bundle is used to configure both doctrine/dbal and doctrine/orm. This can cause issues for people only wanting to use DBAL without ORM (for example https://github.com/symfony/recipes/issues/428). This could be solved by splitting this bundle into two:

• a doctrine/dbal-bundle which is used to configure the entire DBAL stack and can be used standalone
• a doctrine/orm-bundle which is used to configure the ORM and has a hard dependency on the DBAL bundle.

I've previously discussed this with @stof during the EUFOSSA Hackathon and this could very well be done while preserving BC:

• once both bundles exist, the new version of DoctrineBundle requires both ORM and DBAL bundles, injects the configuration into the respective bundles and throws appropriate deprecation notices.
• DoctrineBundle would have to provide a BC layer for all classes that would move to a new namespace, along with deprecation warnings to no longer use them.
• New Symfony recipes for doctrine/dbal-bundle and doctrine/orm-bundle are necessary
• The Symfony Flex stack needs to be changed to no longer require doctrine/doctrine-bundle but doctrine/orm-bundle.

@stof @kimhemsoe @doctrine/team-symfony-integration: can you think of anything I forgot?

[Pheetbag]

I dont know if this is the right place for this, but i would love to know how this is going. I dont see any reference to this issue, will this feature be implemented in the future or is it still and ongoing discussion?

[alcaeus]

We haven't put this on the roadmap (yet). For now I want to finish up work for Symfony 5 and then start thinking about future work.

[dmaicher]

This is now in progress since we discussed it in detail with @stof and @alcaeus at #SymfonyHackday :blush:

https://github.com/doctrine/dbal-bundle

[ChangePlaces]

This is great, as going forwards, it would allow people to use things like onPropertyChanged listeners, that are in the dbal, without having to use the meaty ORM dependency.