Problem/Motivation

During the site install process on the database configuration screen the "Database name" and the "Database username" should be set as required. The form set the fields as required when the PDO driver name is the Drupal driver name. For the by core supported database drivers this is the case. For the contrib database drivers this does not have to be the case. For instance the contrib PostgreSQL fallback driver cannot have the same name as the by core supported PostgreSQL driver. See #3118455: [META] Create contrib fallback database driver for PostgreSQL 9.6. If we in the future also want a separate driver for MariaDB, we will have the same problem (#2985788: Add a separate MariaDB driver).

Proposed resolution

Add a new class variable to \Drupal\Core\Database\Install\Tasks that stores the driver name.

Remaining tasks

Add testing

User interface changes

None

API changes

A new class variable to \Drupal\Core\Database\Install\Tasks that stores the driver name is added. Contrib database drivers need to add this variable to their class override of Tasks.

Data model changes

None

Release notes snippet

A change record needs to be added.

CommentFileSizeAuthor
#2 3118679-2.patch3.34 KBdaffie

Comments

daffie created an issue. See original summary.

daffie’s picture

daffie commented
Status: Active » Needs review
StatusFileSize
new 3118679-2.patch3.34 KB
daffie’s picture

daffie commented
Status: Needs review » Needs work
Issue tags: +beta target

Still needs testing.

daffie’s picture

daffie commented
Issue summary: View changes
salah1’s picture

salah1
Location VA, U.S
commented

Hi @daffie, I would like to write the test classes/methods for this, if that is ok.
Would you like separate patch for the test portion or one big patch from above + tests?
Any other guidance?
I would first get familiar with this part of the code then think about what needs to be tested etc.

Thanks

daffie’s picture

daffie commented

@salah1: Help is always welcome. :)

The problem how can we test this patch other then manual testing. As we are testing something that you only can see on a page it must be a functional test. To make an automated test for this you will need a database driver which name is not equal to its PDO driver name. That rules out all the by core supported drivers. We must then create a fake "contrib" database driver. The problem with contrib database drivers is that in order for them to work they must be copied to the following directory: "DRUPAL_ROOT/driverslib/Drupal/Driver/Database/$driver_name". AFAIK: This is something we cannot do in testing. If somebody has any other idea then please say so.

effulgentsia’s picture

effulgentsia commented
Related issues: +#3118832: Allow custom database drivers to extend and have the same name as the core ones

If we in the future also want a separate driver for MariaDB

I think that's a good use-case for this issue.

the contrib PostgreSQL fallback driver cannot have the same name as the by core supported PostgreSQL driver

I'm not sure that I agree with this. I might change my mind later if there turns out to be convincing reasons for giving it a separate name, but for now, I think it would be good for custom overrides of core drivers to be named the same as the core driver they're overriding. I opened #3118832: Allow custom database drivers to extend and have the same name as the core ones to explore that.

daffie’s picture

daffie commented

Thank you @effulgentsia for your help with this problem.

I think it would be good for custom overrides of core drivers to be named the same as the core driver they're overriding.

It is an idea and I have some problems with it. Lets say that we have a site owner with a Drupal site running on PostgreSQL 10 and he/she uses the contrib fallback driver, because the PostgreSQL database does not have the required pg_trgm extension installed. Lets say after a year the IT-department or the hosting company installs the pg_trgm extension and the site owner now wants to switch to the by core supported driver. To me, the only thing he/she should do is in the settings.php file change the value of the driver from "pgsql_fallback" to "pgsql".

Also if the fallback driver is named the same as the by core supported driver, how does Drupal core which driver to use. They have both the same name. Its like having a contrib module called "node". How does Drupal core know which of two is the real "node" module. If there are more then one contrib database driver for the PostgreSQL database, are they all have the same driver name?

An other problem is that if you install a contrib database driver you have to copy the driver files to DRUPAL_ROOT/drivers/lib/Drupal/Driver/Database/$driver_name. If the contrib database driver has an update you have to also update the files in the special directory. If a site owner forget that then you have a site with a driver directory on version X and its corresponding module on version Y. You are going to get some very strange bugs!

In the database configutation screen during the site installation process the different options are keyed by their driver name. For me I would like to see both options for PostgreSQL (core and fallback) on that list.

The fallback is dependent on the by core supported driver. It is impossible not to have the by core supported installed. Just like with themes I would to have one contrib driver be dependent on an other contrib driver. A theme is for me a template directory with module like capabilities and a database driver should be a driver directory with module like capabilities.

andypost’s picture

andypost
he/him
Primary language Russian
commented
Version: 9.0.x-dev » 9.1.x-dev 
+++ b/core/lib/Drupal/Core/Database/Install/Tasks.php
@@ -203,6 +213,13 @@ protected function checkEngineVersion() {
+    // The class variable $driver is new in drupal:9.0.0 and custom driver need
+    // to set this variable. This code shall be removed in drupal:10.0.0.
+    // See https:///www.drupal.org/node/
+    if (empty($this->driver)) {
+      $this->driver = $this->pdoDriver;

needs to throw deprecation exception and test

effulgentsia’s picture

effulgentsia commented
Version: 9.1.x-dev » 9.0.x-dev

I don't yet see a need for this to be deferred to 9.1.

neelam_wadhwani’s picture

neelam_wadhwani commented
Assigned: Unassigned » neelam_wadhwani
Issue tags: +VbContribution2020
neelam_wadhwani’s picture

neelam_wadhwani commented
Assigned: neelam_wadhwani » Unassigned
xjm’s picture

xjm
she/her
Primary language English
commented
Issue tags: -beta target

The "beta target" tag means the change is allowed and prioritized for commit during the beta phase (i.e., between the release of 9.0.0-beta1 and 9.0.0-rc1.)

This issue isn't necessarily an allowed change during the beta phase -- while I agree with @effulgentsia that it doesn't need to be deferred before 9.0.0-beta1, it also doesn't entirely meet the criteria for allowed changes during the beta phase. (At a minimum, it's adding new functionality.) It'd need discussion and release management signoff to be targeted for the beta phase.

So, untagging for now. If this resolves a major bug/contrib blocker/etc. we can discuss further whether it makes sense to include during beta.

Thanks for working on this!

Version: 9.0.x-dev » 9.1.x-dev

Drupal 9.0.10 was released on December 3, 2020 and is the final full bugfix release for the Drupal 9.0.x series. Drupal 9.0.x will not receive any further development aside from security fixes. Sites should update to Drupal 9.1.0 to continue receiving regular bugfixes.

Drupal-9-only bug reports should be targeted for the 9.1.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.2.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.1.x-dev » 9.3.x-dev

Drupal 9.1.10 (June 4, 2021) and Drupal 9.2.10 (November 24, 2021) were the last bugfix releases of those minor version series. Drupal 9 bug reports should be targeted for the 9.3.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.