Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split bundle into dbal-bundle and orm-bundle #973

Closed
alcaeus opened this issue May 21, 2019 · 12 comments
Closed

Split bundle into dbal-bundle and orm-bundle #973

alcaeus opened this issue May 21, 2019 · 12 comments

Comments

@alcaeus
Copy link
Member

alcaeus commented May 21, 2019

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 symfony/recipes#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
Copy link

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
Copy link
Member Author

alcaeus commented Oct 16, 2019

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
Copy link
Contributor

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

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

@ChangePlaces
Copy link

ChangePlaces commented Nov 24, 2019

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.

@dmaicher
Copy link
Contributor

dmaicher commented Dec 9, 2022

I closed doctrine/dbal-bundle#1 as its quite outdated and I stopped working on it a while ago.

Do you still think we should split the bundles?

@stof
Copy link
Member

stof commented Dec 9, 2022

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.

@ostrolucky
Copy link
Member

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.

@ilukac
Copy link

ilukac commented May 29, 2023

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

@stof
Copy link
Member

stof commented May 29, 2023

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

@ilukac
Copy link

ilukac commented May 29, 2023

Okey, could you just confirm on temporary fixes:

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

@stof
Copy link
Member

stof commented May 29, 2023

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

@ostrolucky
Copy link
Member

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

@ostrolucky ostrolucky closed this as not planned Won't fix, can't repro, duplicate, stale Jul 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants