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

Issue fork drupal-3260007

Command icon 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:

Comments

mondrake created an issue. See original summary.

mondrake’s picture

Title: Decouple Connection::query and MySql's Connection::getServerVersion from the wrapped connection » Decouple Connection::query and MySql's Connection::getServerVersion from the wrapped PDO connection
Status: Active » Needs review
StatusFileSize
new1.27 KB

Status: Needs review » Needs work

The last submitted patch, 2: 3260007-2.patch, failed testing. View results

mondrake’s picture

Title: Decouple Connection::query and MySql's Connection::getServerVersion from the wrapped PDO connection » Decouple Connection from the wrapped PDO connection to allow alternative clients
Status: Needs work » Needs review
StatusFileSize
new4.58 KB
new3.54 KB

Fixed 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.

mondrake’s picture

andypost’s picture

Looks great, just one question about ability to override lastInsertId() from driver side

daffie’s picture

Status: Needs review » Needs work

For the unresolved thread on the MR.

mondrake’s picture

Assigned: Unassigned » mondrake
Issue tags: +Needs change record

We 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.

mondrake’s picture

Assigned: mondrake » Unassigned
Status: Needs work » Needs review

Updated 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.

andypost’s picture

\PDO::FETCH_* maybe just replace'em with some drupalism? curious how dbal/sqlserv doing as they "not bound" to PDO

mondrake’s picture

#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.

daffie’s picture

doctrine/dbal removed the use of those constants in public facing APIs, and pushed it to internals of their PDO drivers implementations.

Doing this in a followup is to me a very good idea.

The MR is for me RTBC.

daffie’s picture

Issue summary: View changes
Status: Needs review » Reviewed & tested by the community
Issue tags: -Needs change record

All code changes look good to me.
I have updated the IS.
I have added a CR.
For me it is RTBC.

mondrake’s picture

Rerolled

yogeshmpawar made their first commit to this issue’s fork.

catch’s picture

This 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).

mondrake’s picture

Status: Reviewed & tested by the community » Postponed

I 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.

mondrake’s picture

Status: Postponed » Needs review
mondrake’s picture

I'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.

mondrake’s picture

Status: Needs review » Reviewed & tested by the community
daffie’s picture

Status: Reviewed & tested by the community » Needs work

I had to change the Connection::open() method to abstract and fix StubConnection, because the method was missing a return statement which violates PHPStan-0.

This 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.

mondrake’s picture

Status: Needs work » Needs review

This is to me a bit of a stupid reason to change the method to an abstract one...

Maybe, 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.

daffie’s picture

Status: Needs review » Reviewed & tested by the community

@mondrake: You are right.

Back to RTBC.

alexpott’s picture

Status: Reviewed & tested by the community » Needs work

This 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.

mondrake’s picture

Only docblock change, setting back to RTBC

mondrake’s picture

Status: Needs work » Reviewed & tested by the community
alexpott’s picture

Version: 10.0.x-dev » 9.5.x-dev
Status: Reviewed & tested by the community » Needs work
Issue tags: -Needs framework manager review

Committed 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.

  • alexpott committed 617d96e on 10.0.x
    Issue #3260007 by mondrake, yogeshmpawar, daffie, andypost: Decouple...

mondrake’s picture

Status: Needs work » Needs review
StatusFileSize
new23.79 KB

Here's a 9.5 patch.

daffie’s picture

Status: Needs review » Reviewed & tested by the community

The reroll for D9.5 looks good to me.

alexpott’s picture

+++ b/core/lib/Drupal/Core/Database/Connection.php
@@ -967,7 +969,7 @@ public function query($query, array $args = [], $options = []) {
         case Database::RETURN_INSERT_ID:
           $sequence_name = $options['sequence_name'] ?? NULL;
-          return $this->connection->lastInsertId($sequence_name);
+          return $this->lastInsertId($sequence_name);

@@ -1264,10 +1266,6 @@ public function insert($table, array $options = []) {
-   *
-   * @see \PDO::lastInsertId
-   *
-   * @internal
    */
   public function lastInsertId(?string $name = NULL): string {

TBH 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.

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed 9093210 and pushed to 9.5.x. Thanks!

I'm not going to publish the CR until we've had a discussion about #34

  • alexpott committed 9093210 on 9.5.x
    Issue #3260007 by mondrake, yogeshmpawar, daffie, andypost: Decouple...
mondrake’s picture

spokje’s picture

Status: Fixed » Needs work

Looks to me like the backport broke the HEAD of 9.5.x-dev for any PHP < 8.1.
(https://www.drupal.org/node/3060/qa)

Example: https://www.drupal.org/pift-ci-job/2388374

Testing Drupal\KernelTests\Core\Database\DatabaseExceptionWrapperTest
...E...                                                             7 / 7 (100%)

Time: 00:06.400, Memory: 4.00 MB

There was 1 error:

1) Drupal\KernelTests\Core\Database\DatabaseExceptionWrapperTest::testPrepareStatementFailOnExecution
ReflectionException: Cannot access non-public member Drupal\mysql\Driver\Database\mysql\Connection::$connection

/var/www/html/core/tests/Drupal/KernelTests/Core/Database/DatabaseExceptionWrapperTest.php:75
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:726

  • alexpott committed 03bfbe6 on 9.5.x
    Revert "Issue #3260007 by mondrake, yogeshmpawar, daffie, andypost:...
alexpott’s picture

I've reverted this on 9.5.x so we can fix this here.

mondrake’s picture

Argh yes

mondrake’s picture

Assigned: Unassigned » mondrake

On this

mondrake’s picture

Assigned: mondrake » Unassigned
Status: Needs work » Needs review
StatusFileSize
new23.84 KB
new933 bytes

Better luck this time?

daffie’s picture

Status: Needs review » Needs work

Testbot is not happy.

mondrake’s picture

Status: Needs work » Needs review

Yeah, but seems unrelated and there are issues to fix HEAD already.

spokje’s picture

Failure on PHP 7.3 on ComposerIntegrationTest is being fixed here: #3282050: Failing HEAD on PHP 7.3 on ComposerIntegrationTest::testComposerLockHash other 2 seem like the "usual random" JS test failures.

Status: Needs review » Needs work

The last submitted patch, 43: 32600007-43.patch, failed testing. View results

daffie’s picture

Status: Needs work » Reviewed & tested by the community

Ther testbot failures are not related to this patch.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 43: 32600007-43.patch, failed testing. View results

alexpott’s picture

Status: Needs work » Fixed

Committed 0c5c369 and pushed to 9.5.x. Thanks!

  • alexpott committed 0c5c369 on 9.5.x
    Issue #3260007 by mondrake, yogeshmpawar, daffie, andypost: Decouple...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

quietone’s picture

Updated the CR to show that this was introduced in 9.5 and published the CR.