Allow custom database drivers to extend and have the same name as the core ones

We need some test coverage here.

+++ b/core/includes/install.inc
@@ -1087,12 +1087,12 @@ function install_profile_info($profile, $langcode = 'en') {
+  $task_class = "Drupal\\Driver\\Database\\{$driver}\\Install\\Tasks";
   if (class_exists($task_class)) {

+++ b/core/lib/Drupal/Core/Database/Database.php
@@ -457,14 +457,14 @@ public static function convertDbUrlToConnectionInfo($url, $root) {
-    // Discover if the URL has a valid driver scheme. Try with core drivers
-    // first.
-    $connection_class = "Drupal\\Core\\Database\\Driver\\{$driver}\\Connection";
+    // Discover if the URL has a valid driver scheme. Try with custom drivers
+    // first, since those can override/extend the core ones.

is it worth abstracting this logic to a helper method somewhere?

Other than that +1 on the idea, and +1 for tests

1. +++ b/core/tests/Drupal/Tests/Core/Database/InstallerObjectTest.php
   @@ -0,0 +1,62 @@
   +  /**
   +   * {@inheritdoc}
   +   */
   +  protected function setUp() {
   +    parent::setUp();
   +    require_once __DIR__ . '/../../../../../includes/install.inc';
   +    $additional_class_loader = new ClassLoader();
   +    $additional_class_loader->addPsr4("Drupal\\Driver\\Database\\fake\\", __DIR__ . "/fixtures/driver/fake");
   +    $additional_class_loader->addPsr4("Drupal\\Core\\Database\\Driver\\corefake\\", __DIR__ . "/fixtures/core-driver/corefake");
   +    $additional_class_loader->addPsr4("Drupal\\Driver\\Database\\corefake\\", __DIR__ . "/fixtures/driver/corefake");
   +    $additional_class_loader->register(TRUE);
   +  }
   

   This will affect all the other unit tests that run afterwards. Well not on DrupalCI because that runs all tests in their own process but as this is very much futzing with classloading it might be a good idea to always run this test in s separate process - there's an annotation for this - @runTestsInSeparateProcesses - see UrlConversionTest for an example.

2. +++ b/core/tests/Drupal/Tests/Core/Database/InstallerObjectTest.php
   @@ -0,0 +1,62 @@
   +    return [
   +      // A driver only in the core namespace.
   +      ['mysql', MysqlInstallTasks::class],
   +
   +      // A driver only in the custom namespace.
   ...
   +
   +      // A driver in both namespaces. The custom one takes precedence.
   +      ['corefake', CustomCoreFakeInstallTasks::class],
   +    ];
   

   If we hard coded the class name I don't think we wouldn't need the ugly require_once in the classes.

@effulgentsia ah I hadn't spotted that. That's why core/tests/fixtures/ exists.

Can we all stop for a moment and take a look at the bigger picture, regarding the workflow of contrib database drivers.
Before I start with that, I would like to thank everybody who is taking an interest in improving contrib database drivers very very much. It is really appreciated! :)

Now for that bigger picture

There are 2 kinds of contrib database drivers:
- the first has only a driver directory. Lets call them type A;
- the second one has a driver directory and a module part. Lets call those type B.

I am working on creating a fallback driver for PostgreSQL and lets take that as an example. At the moment it only has a driver directory and therefor its a type A. When the by core supported driver for PostgreSQL starts using the pg_trgm extension, the contrib driver will need to undo that and therefor needs a module part and becomes a contrib driver of type B.

The workflow of installing a contrib database driver

Installing the contrib driver is as follows:
1. Download/require the contrib driver;
2. Copy the contents of the "drivers" directory from the module to the root of the Drupal project/installation.
3. If the contrib driver has a module part, the module must be enabled.

I am not sure when working with composer if this can be automated from the contrib driver or does the site builder/owner has to use scaffolding in their composer.json to copy the "drivers" directory them self. This is how it works now. Is this how we want it to be?

The workflow of updating a contrib database driver

Updating the contrib driver is as follows:
1. Downloading the updated contrib driver;
2. Copy the contents of the "drivers" directory from the module to the root of the Drupal project/installation and replacing the existing one.
3. Running the site updates script.

Site builders/owner are not used to coping files after they have run the command composer update. If they forget they will still be working with the old version of the driver directory. If they have a type B contrib driver they will be using 2 different versions. One for the driver directory and one for the module part of the contrib driver. If a site builder/owner runs the update script before copying the update to the "drivers" directory, a lot can go wrong. Is this how we want it to be?

The workflow of moving from using a contrib driver to using a by core supported driver

Moving to using the by core supported driver (with the current patch):
1. Running the update process that will be provided by the contrib driver (creating the pg_trgm indexes);
2. Deleting the contents of the "drivers" directory in the root of the Drupal project/installation;
3. Disabling the contrib module (if type B).

Testing the transition is for a site builder/owner not very easy to do.
If somebody wants to know if a site is using a contrib driver, the only way to check for that is looking if the "drivers" directory in the root of the Drupal project/installation is used or not. The driver setting in the settings.php will be the same for contrib and the by core supported drivers.

Moving to using the by core supported driver (without the current patch):
1. Running the update process that will be provided by the contrib driver (creating the pg_trgm indexes);
2. Change the driver setting from "pgsql-fallback" to "pgsql" in the settings.php file.

Can we take a look at the big picture of how we want the workflow to be for contrib database drivers before we start implementing it. Again a very big thank you to everybody who is taking an interest in contrib database drivers!

@daffie +1 (and a bit more). The whole process of registering and moving code about for contrib db drivers is extremely convoluted. It's driven by the use of magic driver namespaces - ie. Drupal\\Driver\\Database\\{$driver}\\Connection and you're 100% right that the whole process is very clunky and fraught with possible ways to break. For example the update process in #17 will is likely fail if the contrib driver removes a file.

I think we need to come up with a method that doesn't require anyone to move code about anywhere. #3112476: Always set $info['namespace'] on database connection info is going to set a namespace on all connections including core and think this is the start of this. Once we do that we need away of providing the namespace in the URL instead of the driver. And simple instructions for how to add the contrib db driver to the autoloader in settings.php.

That said I don't think that #17 and #18 block this issue. Is only that looking at this issue makes us aware of just how painful all of this is.

I think the changes here are okay and will help us provide BC drivers in the short term but we should also continue to work on making things much easier for contrib drivers.

@effulgentsia there’s no need for another composer installers Drupal type. I scoped out a plan with @daffie a couple of days ago and he’s going to put it in a new issue as I don’t think any of this needs to block us here.

All the code changes look good to me.
For all code changes there is testing.
All the comment changes also look in order.
The moving of the fixture is to me also a good idea.
The change record is there.
For me it is RTBC.

Re #7 I don't think so. @daffie and I are working on a new way to autoload DB drivers that will mean that custom and contrib drivers no longer need to move code and it's likely this code will be refactored further so let's not preempt that work. @daffie hasn't yet (as far as I know created an issue on d.o for this work but that will happen in time).

Committed and pushed c4f0d96291 to 9.0.x and c3b1069774 to 8.9.x. Thanks!

@alexpott: I have created that issue. See: #3120096: Support contrib database driver directories in a fixed location in a module.