phoenix icon indicating copy to clipboard operation
phoenix copied to clipboard

Split bundle into dbal-bundle and orm-bundle

Open alcaeus opened this issue 5 years ago • 4 comments

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?

alcaeus avatar May 21 '19 17:05 alcaeus

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?

Pheetbag avatar Oct 16 '19 21:10 Pheetbag

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.

alcaeus avatar Oct 16 '19 21:10 alcaeus

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

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

dmaicher avatar Nov 23 '19 16:11 dmaicher

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.

ChangePlaces avatar Nov 24 '19 21:11 ChangePlaces

I closed https://github.com/doctrine/dbal-bundle/pull/1 as its quite outdated and I stopped working on it a while ago.

Do you still think we should split the bundles?

dmaicher avatar Dec 09 '22 14:12 dmaicher

Well, it would greatly improve the DX for project wanting to use DBAL without the ORM (as the recipe currently assumes the ORM is wanted). But it would indeed require time resources to perform the split without letting it stale as in-progress. And we would need to define a good upgrade path.

stof avatar Dec 09 '22 16:12 stof

I think it's fine thing to do, but also I don't think it's realistic at the moment because it has low enough of importance that nobody will want to pick this up.

ostrolucky avatar Jan 06 '23 09:01 ostrolucky

Hey @alcaeus, I just run into this issue. Any news? :)

ilukac avatar May 29 '23 09:05 ilukac

@ilukac no progress is being done on this right now. the 2 comments before yours still apply.

stof avatar May 29 '23 10:05 stof

Okey, could you just confirm on temporary fixes:

  • either install doctrine/orm
  • or remove the ORM related config?

ilukac avatar May 29 '23 10:05 ilukac

If you don't want to use the ORM, you can indeed remove the ORM-related config added by the recipe.

stof avatar May 29 '23 11:05 stof

I don't see this getting traction, let's close

ostrolucky avatar Jul 21 '23 01:07 ostrolucky