Fatal error with `doctrine/dbal` 4.x

[ddebin]

Fatal error with `doctrine/dbal` 4.x

[cleptric]

Support for doctrine/dbal v4.0 was added in 4.14.0.

[cleptric]

It is being worked on.

[cleptric]

We'll add support for DBAL v4; I can't give you a timeline at this point.

[ste93cry]

Unfortunately, since Doctrine is an optional dependency of this package, we don't require it in composer.json besides for development purposes, hence we have no way to prevent the installation of an unsupported version. This is one of the reasons for which I strongly believe that:

• All tracing features should not be enabled by default (and this is a lost battle...)
• We should move the tracing integrations into separate packages, so that we can declare for real the dependencies they really supports in the composer.json

[alexislefebvre]

@ste93cry What about declaring a conflict with the unsupported version, until it is supported?

[msphn]

Until resolved I solved that by going with orm 3.* but constraining dbal.

"doctrine/dbal": "3.*",
"doctrine/orm": "^3.0.0",

[Jean85]

@ste93cry What about declaring a conflict with the unsupported version, until it is supported?

That would prevent users to use the whole bundle if they use DBAL 4, which is an issue only if you enable tracing.

[ddebin]

See doctrine/orm 3.0.0 & doctrine/dbal 4.0.0

[Jean85]

Are you using DBAL 3 or 4?

[ddebin]

Are you using DBAL 3 or 4?

DBAL 4.x, it's more of a problem with doctrine/dbal 4

[Jean85]

Return type switched from bool to void, I don't think we can make the interface cross compatible...

bindValue($param, $value, $type = Doctrine\DBAL\ParameterType::STRING): bool
bindValue(string|int $param, mixed $value, Doctrine\DBAL\ParameterType $type): void

We need to create another one, and this is probably not even the only BC that we need to handle.

[ddebin]

Related to #579

[tacman]

When creating a new symfony project with --webapp, composer.json adds "doctrine/orm:^3.0" to the requires section. I wish instead it were "^2.1||^3.0", and let composer figure out which version to use based on what the dependencies support.

That would help in this case, as well as for API Platform api-platform/core#6150

[ddebin]

Could anyone point out how to disable tracing ? 🙂

[ste93cry]

You can disable tracing as a whole using:

sentry:
  tracing:
    enabled: false

or you can disable tracing specifically for DBAL using:

sentry:
  tracing:
    dbal:
      enabled: false

[ddebin]

@ste93cry What about declaring a conflict with the unsupported version, until it is supported?

That would prevent users to use the whole bundle if they use DBAL 4, which is an issue only if you enable tracing.

@Jean85 Can't use the whole bundle with DBAL 4, even with tracing disabled.

[BenMorel]

Can't use the whole bundle with DBAL 4, even with tracing disabled.

Indeed, even with the whole bundle disabled, the application still fails with:

Fatal error: Declaration of Sentry\SentryBundle\Tracing\Doctrine\DBAL\TracingStatementForV3::bindValue($param, $value, $type = Doctrine\DBAL\ParameterType::STRING): bool must be compatible with Doctrine\DBAL\Driver\Statement::bindValue(string|int $param, mixed $value, Doctrine\DBAL\ParameterType $type): void in /app/vendor/sentry/sentry-symfony/src/Tracing/Doctrine/DBAL/TracingStatementForV3.php on line 20

[ste93cry]

I believe that at this point, a conflict is the only viable solution until support for the newer version is worked on @Jean85