Skip to content

Support doctrine 3.x #770

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

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Support doctrine 3.x #770

wants to merge 5 commits into from

Conversation

erikn69
Copy link
Contributor

@erikn69 erikn69 commented Apr 21, 2025

https://www.doctrine-project.org/projects/doctrine-orm/en/3.3/reference/configuration.html

The code was moved from \DebugBar\Bridge\DoctrineCollector to \DebugBar\Bridge\Doctrine\DoctrineCollector and the middleware was added, it keeps 2.x support on \DebugBar\Bridge\DoctrineCollector

the middleware wraps doctrine connection, is there a better way to achieve this?

UPDATE1: it seems that doctrine 3.x does not support php 8.0
UPDATE2: durationBackground added, events like transaction are now better differentiated, events are avoided from being counted as statements

@erikn69 erikn69 force-pushed the patch-52 branch 2 times, most recently from 7d8934c to 4ebd1f6 Compare April 21, 2025 15:31
@erikn69 erikn69 force-pushed the patch-52 branch 2 times, most recently from 1cc1e98 to 179644f Compare April 22, 2025 16:23
@barryvdh
Copy link
Collaborator

Would it make more sense to create php-debugbar/doctrine-bridge or something?

@barryvdh
Copy link
Collaborator

It's a bit difficult to pin dependencies and things like that. And making changes or upgrading in the future with breaking changes, make it also difficult.

@erikn69
Copy link
Contributor Author

erikn69 commented Apr 25, 2025

Would it make more sense to create php-debugbar/doctrine-bridge or something?

Maybe, but since there was already support for 2x I thought about adding it here.
In that case, shouldn't all the bridges be separated? Monolog for example

It's a bit difficult to pin dependencies and things like that. And making changes or upgrading in the future with breaking changes, make it also difficult.

Is it because of the integration test? Yes, it's difficult.

@barryvdh
Copy link
Collaborator

well yeah it's mostly difficult because we don't actually add the depencies so we cannot bump anything.

@erikn69
Copy link
Contributor Author

erikn69 commented Apr 25, 2025

In my opinion, the only thing that saves this type of thing is that it is not a production package, you can adapt it to your local environment in your own way.

@drmax24
Copy link

drmax24 commented Apr 30, 2025

merge?.. New way is not worse performance-wise right?

@erikn69
Copy link
Contributor Author

erikn69 commented Apr 30, 2025

New way is not worse performance-wise right?

That shouldn't be the case, but try it and tell us, I don't use Doctrine, I'm just trying to help

@barryvdh
Copy link
Collaborator

I think I'm gonna make a seperate repo. Just thinking about how to do it cleanly. Shall I make the base package and let @erikn69 PR his code (copy paste) it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

setSQLLogger is deprecated Doctrine integration outdated
3 participants