Problem/Motivation
While working on #3259709: Create the database driver for MySQLi, I realised there are a couple of direct calls to the wrapped PDO connection that, if moved to the Drupal connection class, will facilitate writing code for non-PDO db drivers.
Proposed resolution
Refactor code to call Drupal's Connection methods instead, that in turn interact with the wrapped connection at hand.
Remaining tasks
TBD
User interface changes
None
API changes
The method Drupal\Core\Database\Connection::lastInsertId() has changed from an @internal to being part of the public Database API.
Data model changes
None
Release notes snippet
TBD
| Comment | File | Size | Author |
|---|---|---|---|
| #43 | interdiff_32-43.txt | 933 bytes | mondrake |
| #43 | 32600007-43.patch | 23.84 KB | mondrake |
Issue fork drupal-3260007
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3260007-decouple-connection-from
changes, plain diff MR !1704
Comments
Comment #2
mondrakeComment #4
mondrakeFixed tests and enlarged scope a bit. We also have a test in DatabaseExceptionWrapperTest that assumes that the wrapped connection is PDO - we need to skip that for non-PDO connections.
Comment #6
mondrakeComment #7
andypostLooks great, just one question about ability to override
lastInsertId()from driver sideComment #8
daffie commentedFor the unresolved thread on the MR.
Comment #9
mondrakeWe also need to cleanup docs to reflect that PDO is "one" possibility to connect, not the "only" one as it's currently saying. And yes, we need a CR. Working on it.
Comment #10
mondrakeUpdated the docblocks of a bunch of files in the Database namespace to relax vs PDO strictness.
We keep using \PDO::FETCH_* constants in Statement and the 'pdo' connection option, we cannot change that without BC break.
Comment #11
andypostComment #12
andypost\PDO::FETCH_*maybe just replace'em with some drupalism? curious how dbal/sqlserv doing as they "not bound" to PDOComment #13
mondrake#12 is a big topic, can we please discuss it in a follow up. FWIW: doctrine/dbal removed the use of those constants in public facing APIs, and pushed it to internals of their PDO drivers implementations.
Comment #14
daffie commentedDoing this in a followup is to me a very good idea.
The MR is for me RTBC.
Comment #15
daffie commentedAll code changes look good to me.
I have updated the IS.
I have added a CR.
For me it is RTBC.
Comment #16
mondrakeRerolled
Comment #18
catchThis looks very good to me, a lot less changes than I was expecting.
Tagging for framework manager review because it'd be worth a second set of committer eyes (or at least, if another committer doesn't get to it, to remind me to review it again properly before commit).
Comment #19
mondrakeI had to change the
Connection::open()method to abstract and fix StubConnection, because the method was missing a return statement which violates PHPStan-0.But now we have an unrelated missing PHPStan baseline update, which would not be proper to fix here.
Comment #20
mondrakeComment #21
mondrakeI'll be bold and mark it back to RTBC. The only change since the RTBC in #15 was the
Connection::open()method turned to abstract and fix StubConnection, because the method was missing a return statement which violates PHPStan-0. So in a sense it's a must do if we want to respect PHPStan-0.Comment #22
mondrakeComment #23
daffie commentedThis is to me a bit of a stupid reason to change the method to an abstract one, but fine. The 2 contrib database drivers at the moment are overriding the method, so the change is not a problem to me.
I found one nitpick, but for the rest it is RTBC for me.
Comment #24
mondrakeMaybe, but here it's not about being smart or stupid, it's about whether we embrace PHPStan or not.
In fact, I do not see any possibility to implement a driver without writing your own
open()method. An default empty one is just wrong. That matches the purpose of an abstract base method IMHO.Comment #25
daffie commented@mondrake: You are right.
Back to RTBC.
Comment #26
alexpottThis looks like a really nice clean up. I read all the comments and code changes and left a comment on the one that I think can improved.
Comment #27
mondrakeOnly docblock change, setting back to RTBC
Comment #28
mondrakeComment #29
alexpottCommitted 617d96e and pushed to 10.0.x. Thanks!
I think we should backport this change to 9.5.x because there are no real API changes here and having 9.5.x and 10.0.x aligned is helpful.
Comment #32
mondrakeHere's a 9.5 patch.
Comment #33
daffie commentedThe reroll for D9.5 looks good to me.
Comment #34
alexpottTBH I think it was fine for this to remain @internal. Nothing from outside a DB driver module should ever call this. And I think DB driver modules are fine to call through to their expected client. I agree that the Connection class should call its own method though.
Going to proceed here with the commit but I think it would be fine to open a follow-up to add @internal back and also to other places in the current DB API that we don't think should be called by anything external to the DB API or a driver module.
Comment #35
alexpottCommitted 9093210 and pushed to 9.5.x. Thanks!
I'm not going to publish the CR until we've had a discussion about #34
Comment #37
mondrake#34 makes sense. Opened #3281962: Add @internal to Database API methods that should only be called by driver code.
Comment #38
spokjeLooks to me like the backport broke the HEAD of
9.5.x-devfor any PHP < 8.1.(https://www.drupal.org/node/3060/qa)
Example: https://www.drupal.org/pift-ci-job/2388374
Comment #40
alexpottI've reverted this on 9.5.x so we can fix this here.
Comment #41
mondrakeArgh yes
Comment #42
mondrakeOn this
Comment #43
mondrakeBetter luck this time?
Comment #44
daffie commentedTestbot is not happy.
Comment #45
mondrakeYeah, but seems unrelated and there are issues to fix HEAD already.
Comment #46
spokjeFailure on PHP 7.3 on
ComposerIntegrationTestis being fixed here: #3282050: Failing HEAD on PHP 7.3 on ComposerIntegrationTest::testComposerLockHash other 2 seem like the "usual random" JS test failures.Comment #48
daffie commentedTher testbot failures are not related to this patch.
Comment #50
alexpottCommitted 0c5c369 and pushed to 9.5.x. Thanks!
Comment #53
quietone commentedUpdated the CR to show that this was introduced in 9.5 and published the CR.