Use AbstractDriverMiddleware class instead of own implementation

[oleg-andreyev]

Use AbstractDriverMiddleware class instead of own implementation, by reusing common abstract class it's possible to unwind wrappedDriver.

I have a case DamienHarper/auditor#184 when auditor & sentry don't play well.

• While working on fix noticed that sentry does not utilize AbstractDriverMiddleware and implements everything.
• Also it's impossible to detect if driver was wrapped.

[Jean85]

This seems a very interesting approach! We should check if this limits compatibility with DBAL in any way, otherwise LGTM! 👍

[ste93cry]

The abstract class was introduced in DBAL 3.3, while we also support previous versions. Either we raise the requirement in the composer.json (technically speaking it doesn't change anything because it's a dev dependency, but at least we make it clear to the reader that we support that minimum version), or we cannot proceed. According to Packagist, the only relevant change is that we would drop the support for Composer 1, which imho is acceptable.

Also it's impossible to detect if driver was wrapped.

I fail to understand how this change would be helpful in this case. There is no public API to get the wrapped driver, and checking whether AbstractDriverMiddlware class is extended or not has nothing to do with it.

[oleg-andreyev]

While there is no public API (which is a miss of DBAL), if connection is instance of is AbstractDriverMiddleware there is $wrappedDriver and you could get it wil reflection (I know it's bad)

[oleg-andreyev]

I've raised issue about missing API: doctrine/dbal#6308

[cleptric]

This needs a proper discussion, we can’t just raise minimum versions.