doctrine-mysql-come-back
doctrine-mysql-come-back copied to clipboard
facile-it
Deprecation warning
Hi
Thanks for this library - it's been working very well for us. I'm seeing this deprecation warning in our Symfony project
The "Doctrine\DBAL\Connection::__construct()" method is considered internal The connection can be only instantiated by the driver manager. It may change without further notice. You should not extend it from "Facile\DoctrineMySQLComeBack\Doctrine\DBAL\Connection".
This is with doctrine/dbal 2.12.0. I imagine this isn't a real problem yet, but annoying as this gets flagged up as part of our build process. Is there a way to achieve what this library does without overriding the constructor? Or perhaps a way to turn off the warning at least.
Regards
Steve
We could try to use a decorator pattern instead of extension, but I'm not sure if everything that we need to accomplish is doable in that way...
Umh, this seems counter-intuitive, but avoiding extending Doctrine\DBAL\Connection is NOT doable, you get this error:
Doctrine\DBAL\Exception: The given 'wrapperClass' Facile\DoctrineMySQLComeBack\Doctrine\DBAL\FunctionalTest\Connection has to be a subtype of \Doctrine\DBAL\Connection.
vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php:221
vendor/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php:195
...
Yeah that does seem odd, if the only way to wrap is by extending then either the deprecation message is incorrect or doctrine needs to provide another way to wrap the connection. I suspect we might have to live with the warning for a while until this is resolved by doctrine and an way forward becomes apparent.
The deprecation warning seems to come from Symfony's DebugClassLoader.
I think the only way is to disable E_USER_DEPRECATED errors in production, but it seems not possible to remove them completely.
Another important deprecation to consider:
\Doctrine\DBAL\Driver\PDOMySql\Driver is deprecated in favor of \Doctrine\DBAL\Driver\PDO\MySQL\Driver, which is final.
https://github.com/doctrine/dbal/pull/4144
Closing as everything is now correctly handled in 2.0. Unfortunately, I don't have the bandwidth to fix the deprecations in 1.x, and I'm not even sure those are fixable.