-
Notifications
You must be signed in to change notification settings - Fork 62
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
Doctrine\DBAL\Driver\ExceptionConverterDriver is deprecated #129
Comments
I don't see a way to fix this in a forward compatible way 😕 We can fix it here for doctrine/dbal 3 and not implement that interface anymore. Checked doctrine/dbal#4118 and https://github.com/doctrine/dbal/pull/4129/files Or do you see a way to get rid of the deprecation already? |
Can't we just stop implementing ExceptionConverterDriver? |
Well that will probably have side effects? See https://github.com/doctrine/dbal/blob/2.11.x/lib/Doctrine/DBAL/DBALException.php#L181 |
Do you think? I see that exception is converted with the old interface, otherwise is re-thrown as generic Exception. Is that so different? |
I think it would be bad as the test environment would behave differently than dev/prod environments if the underlying driver implements For example I'm mostly using If now in the tests the |
I quickly confirmed it with a functional test. This works without any changes: public function testWillThrowSpecificException(): void
{
$this->expectException(TableNotFoundException::class);
$this->connection->insert('does_not_exist', ['foo' => 'bar']);
} and it fails when
|
I see. |
Why not create a different One would use a Makes sure that using the interface is opt-out, it's backwards-compatible, and when Doctrine DBAL removes the class, migration path is quicker, since the legacy interface might then have a runtime check on the interface. WDYT? |
@Pierstoval yes for DBAL 3 we will need a But for dbal |
Let's wait until DBAL 3 release then 👍 |
Hello, Does it make transactions rollback fail ? |
No. Its just a deprecation. You can safely ignore it. |
Compatibility with dbal 3 is merged & released. As I don't see any way of fixing this for dbal 2.x (unless there is some forward compatibility layer on dbal 2.x for it) I will close here. |
@dmaicher Would creating a new release that's only compatible with dbal 3.x be an option? I'll understand if you're not willing to maintain 2 release streams, but this would be the cleanest option IMO. |
@BenMorel are you still seeing this deprecation when using dbal 3? |
@dmaicher Sorry, I think I misunderstood the problem. We're using doctrine/dbal 2.13. I guess this boils down to releasing a version that would be compatible with 2.11+ only? The aim being to have a version that's clear of deprecation warnings. |
This is impossible. The driver interface is deprecated on dbal 2.x, but there is no replacement as far as I see. So we need to use it on 2.x as otherwise the functionality is broken. |
Oh right, I see now. They've deprecated the Anyway, sorry for the noise! |
After upgrading to doctrine/dbal 2.11:
The text was updated successfully, but these errors were encountered: