-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Cache] Support decorated Dbal drivers in PdoAdapter #42011
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
Conversation
Can you provide a test for this change, please? I think we should target 4.4 and file this as a bugfix. |
Test added and rebased on 4.4. |
$config->setMiddlewares([$middleware]); | ||
|
||
$connection = DriverManager::getConnection(['driver' => 'pdo_sqlite', 'path' => self::$dbFile], $config); | ||
} else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is for doctrine/dbal v2
, which doesn't have the middleware. Not sure if the test should cover this or something like a SkippedTestSuiteError
should be thrown.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather call $this->markTestSkipped
as the feature does not exist properly for v2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. If the test is irrelevant for DBAL 2, just skip it if we‘re not testing against DBAL 3.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. If the test is irrelevant for DBAL 2, just skip it if we‘re not testing against DBAL 3.
I don't think that this fix is irrelevant for DBAL 2, because you could still decorate/wrap the driver manually anyway, see #42022 and the originating issue getsentry/sentry-symfony#530.
In general, I think we should change the switch
to use $this->conn->getDatabasePlatform()->getName()
as a reliable source of information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because you could still decorate/wrap the driver manually anyway
But not as official dbal v2 functionality right? You can pass a driverClass
to the configuration, which is then constructed without arguments, making it less usable to function as decorator. Or it'd be via Reflection changing the private property _driver
to public at runtime. Which is in my opinion already such an edge case, that Symfony shouldn't have to test against that.
src/Symfony/Component/Cache/Tests/Adapter/PdoDbalAdapterTest.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/Cache/Tests/Adapter/PdoDbalAdapterTest.php
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this PR! This should fix #42022
I don't understand why you didn't use $this->conn->getDatabasePlatform()->getName()
as you suggested yourself though...
$config->setMiddlewares([$middleware]); | ||
|
||
$connection = DriverManager::getConnection(['driver' => 'pdo_sqlite', 'path' => self::$dbFile], $config); | ||
} else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. If the test is irrelevant for DBAL 2, just skip it if we‘re not testing against DBAL 3.
I don't think that this fix is irrelevant for DBAL 2, because you could still decorate/wrap the driver manually anyway, see #42022 and the originating issue getsentry/sentry-symfony#530.
In general, I think we should change the switch
to use $this->conn->getDatabasePlatform()->getName()
as a reliable source of information.
I did though? See Edit: I see there's a slight difference ( |
My suggestion is to change the whole |
That's good feedback 👍 . Though I'd like to get some feedback on that from a Symfony maintainer as well, if possible. They're the ones to approve the PR after all. |
@nicolas-grekas already weighed in in #42022 (comment), but I'm not sure if he got the full implication of my suggestion. |
That works for me if the resulting code remains compatible with the range of dbal versions we support currently. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In patch-types.php, we maintain a list of files that should be ignored by that script. Please add your new DriverWrapper
fixture there to make the tests pass.
LGTM, but I'd turn the |
Thank you @Jeroeny. |
This PR was squashed before being merged into the 5.4 branch. Discussion ---------- [Lock] Use platform to identify the PDO driver | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | Fix #43048 | License | MIT This should fix the issue in the same way we did for #42011. I'm not sure if I should add/change any test... Commits ------- 687a7ed [Lock] Use platform to identify the PDO driver
Doctrine v3 supports middleware for Drivers. Upon creating the Connection,
middleware->wrap(Driver): Driver
is called, in which the middleware can wrap/decorate the Driver class. So that it can perform tracing for example.When this happens, the Driver class inside the Connection is no longer one of Doctrine's well known Driver classes. The
PdoAdapter
uses this class to determine the database platform. Which breaks once the Driver is decorated and no longer one of the classes listed in thePdoAdapter
.Since Dbal exposes this middleware as a feature, I think it would be nice for the
PdoAdapter
to support this.To solve this, the
getDatabasePlatform
can be used. This returns aDoctrine\DBAL\Platforms\AbstractPlatform
which defines the abstract methodgetName
. This returns a value very similar to the list in thePdoAdapter
. The names don't match exactly, so therefor a small mapping is done to get right the name used in the adapter. As far as a I know, there'd be no other implications with this change.Related: getsentry/sentry-symfony#530