Comments

effulgentsia created an issue. See original summary.

effulgentsia’s picture

Status: Active » Needs review
StatusFileSize
new1.88 KB

Status: Needs review » Needs work

The last submitted patch, 2: test-pgsql-fallback.patch, failed testing. View results

effulgentsia’s picture

Status: Needs work » Needs review
StatusFileSize
new2.02 KB
new553 bytes

Status: Needs review » Needs work

The last submitted patch, 4: test-pgsql-fallback-4.patch, failed testing. View results

effulgentsia’s picture

The console output of the test run in #4 surfaced a legitimate bug.

Various Views tests, such as Drupal\Tests\datetime\Kernel\Views\FilterDateTimeTest, fail because they end up using the views.date_sql service (which is MySQL-specific) instead of the pgsql.views.date_sql service. The reason they don't use the latter is because per BackendCompilerPass, that's based on $container->get('database')->driver(), which for the fallback driver is PgsqlFallback, so we'd need a service named PgsqlFallback.views.date_sql.

I think we should improve BackendCompilerPass to check for a service based on $container->get('database')->databaseType() if it can't find one based on $container->get('database')->driver().

effulgentsia’s picture

Status: Needs work » Needs review
StatusFileSize
new2.7 KB
new516 bytes

For now, just doing this to see how far it gets us.

Status: Needs review » Needs work

The last submitted patch, 7: test-pgsql-fallback-7.patch, failed testing. View results

effulgentsia’s picture

Status: Needs work » Needs review
StatusFileSize
new5.72 KB
new2.58 KB

A bit more progress, but not much.

Status: Needs review » Needs work

The last submitted patch, 9: test-pgsql-fallback-9.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

effulgentsia’s picture

Status: Needs work » Needs review
StatusFileSize
new6.48 KB
new637 bytes

This should fix a bunch of the functional tests.

Status: Needs review » Needs work

The last submitted patch, 11: test-pgsql-fallback-11.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

daffie’s picture

@effulgentsia: Thank for working on this. Some test failures you have come from the fact that the fallback driver is located in a module. In #3129043: Move core database drivers to modules of their own, I have the same problems. I fixed some test with the following code changes:

diff --git a/core/tests/Drupal/KernelTests/Core/Cache/EndOfTransactionQueriesTest.php b/core/tests/Drupal/KernelTests/Core/Cache/EndOfTransactionQueriesTest.php
index 7ff31796d4..1a0e4f6a7d 100644
--- a/core/tests/Drupal/KernelTests/Core/Cache/EndOfTransactionQueriesTest.php
+++ b/core/tests/Drupal/KernelTests/Core/Cache/EndOfTransactionQueriesTest.php
@@ -31,12 +31,12 @@ class EndOfTransactionQueriesTest extends KernelTestBase {
    * {@inheritdoc}
    */
   protected function setUp(): void {
+    parent::setUp();
+
     if (!class_exists($this->getDatabaseConnectionInfo()['default']['namespace'] . '\Connection')) {
       $this->markTestSkipped(sprintf('No logging override exists for the %s database driver. Create it, subclass this test class and override ::getDatabaseConnectionInfo().', $this->getDatabaseConnectionInfo()['default']['driver']));
     }
 
-    parent::setUp();
-
     $this->installSchema('system', 'sequences');
     $this->installEntitySchema('entity_test');
     $this->installEntitySchema('user');
diff --git a/core/tests/Drupal/TestSite/Commands/TestSiteTearDownCommand.php b/core/tests/Drupal/TestSite/Commands/TestSiteTearDownCommand.php
index 0713af5c7c..6a37295998 100644
--- a/core/tests/Drupal/TestSite/Commands/TestSiteTearDownCommand.php
+++ b/core/tests/Drupal/TestSite/Commands/TestSiteTearDownCommand.php
@@ -80,6 +80,7 @@ protected function execute(InputInterface $input, OutputInterface $output) {
   protected function tearDown(TestDatabase $test_database, $db_url): void {
     // Connect to the test database.
     $root = dirname(dirname(dirname(dirname(dirname(__DIR__)))));
+    require_once $root . '/core/includes/bootstrap.inc';
     $database = Database::convertDbUrlToConnectionInfo($db_url, $root);
     $database['prefix'] = ['default' => $test_database->getDatabasePrefix()];
     Database::addConnectionInfo(__CLASS__, 'default', $database);
diff --git a/core/tests/Drupal/Tests/Core/Test/TestSetupTraitTest.php b/core/tests/Drupal/Tests/Core/Test/TestSetupTraitTest.php
index d0b8283566..d8d4d760bb 100644
--- a/core/tests/Drupal/Tests/Core/Test/TestSetupTraitTest.php
+++ b/core/tests/Drupal/Tests/Core/Test/TestSetupTraitTest.php
@@ -25,8 +25,10 @@ class TestSetupTraitTest extends UnitTestCase {
    * @covers ::changeDatabasePrefix
    */
   public function testChangeDatabasePrefix() {
+    $root = dirname(__FILE__, 7);
+    require_once $root . '/core/includes/bootstrap.inc';
     putenv('SIMPLETEST_DB=pgsql://user:pass@127.0.0.1/db');
-    $connection_info = Database::convertDbUrlToConnectionInfo('mysql://user:pass@localhost/db', '');
+    $connection_info = Database::convertDbUrlToConnectionInfo('mysql://user:pass@localhost/db', $root);
     Database::addConnectionInfo('default', 'default', $connection_info);
     $this->assertEquals('mysql', Database::getConnectionInfo()['default']['driver']);
     $this->assertEquals('localhost', Database::getConnectionInfo()['default']['host']);
@@ -35,7 +37,7 @@ public function testChangeDatabasePrefix() {
     // used to avoid unnecessary set up.
     $test_setup = $this->getMockForTrait(TestSetupTrait::class);
     $test_setup->databasePrefix = 'testDbPrefix';
-    $test_setup->root = '';
+    $test_setup->root = $root;
 
     $method = new \ReflectionMethod(get_class($test_setup), 'changeDatabasePrefix');
     $method->setAccessible(TRUE);
diff --git a/core/tests/Drupal/Tests/Scripts/TestSiteApplicationTest.php b/core/tests/Drupal/Tests/Scripts/TestSiteApplicationTest.php
index caabc84f75..c8e0a9e5f2 100644
--- a/core/tests/Drupal/Tests/Scripts/TestSiteApplicationTest.php
+++ b/core/tests/Drupal/Tests/Scripts/TestSiteApplicationTest.php
@@ -43,6 +43,7 @@ protected function setUp(): void {
     $php_executable_finder = new PhpExecutableFinder();
     $this->php = $php_executable_finder->find();
     $this->root = dirname(dirname(substr(__DIR__, 0, -strlen(__NAMESPACE__))));
+    require_once $this->root . '/core/includes/bootstrap.inc';
   }
 
   /**

I fixed the test Drupal\Tests\system\Functional\Module\InstallUninstallTest by making the module hidden.

@alexpott has problem with how the fallback driver is extending the classes of the by core supported PostgreSQL driver. I have no idea how to do it in another way. Waiting for another solution from @alexpott. When you have an idea how to solve it then please speak up.

effulgentsia’s picture

Status: Needs work » Needs review
StatusFileSize
new7.62 KB
new5.31 KB

Thanks @daffie! That helped. Here's a slightly centralized implementation of that for this issue's purposes to keep this patch smaller, but your approach is probably the better one for #3129043: Move core database drivers to modules of their own.

I fixed the test Drupal\Tests\system\Functional\Module\InstallUninstallTest by making the module hidden.

I'm not yet clear on why that's needed. That test should be able to install and uninstall this module just as successfully as all the core ones. I need to investigate that more.

daffie’s picture

I think one should not be able to uninstall the module that provides the database driver in use.

effulgentsia’s picture

If we want core to enforce that, then let's open an issue for that. That would also imply that core's installer needs to enable the module if that's the selected driver.

Status: Needs review » Needs work

The last submitted patch, 14: test-pgsql-fallback-14.patch, failed testing. View results

daffie’s picture

That would also imply that core's installer needs to enable the module if that's the selected driver.

That is next on my list. Right after #3129043: Move core database drivers to modules of their own has landed.

effulgentsia’s picture

Status: Needs work » Needs review
StatusFileSize
new7.62 KB
new1.35 KB
--- /dev/null
+++ b/core/modules/system/tests/modules/database_statement_monitoring_test/src/PgSqlFallback/Connection.php

Oops. PgSqlFallback is incorrectly capitalized. It should be PgsqlFallback. This fixes that.

Interdiffs aren't as useful when file names are changed, so instead attaching just a plain diff between the #14 patch and this one.

Status: Needs review » Needs work

The last submitted patch, 19: test-pgsql-fallback-19.patch, failed testing. View results

daffie’s picture

Related issues: +#3129043: Move core database drivers to modules of their own

When I look at the changes in the current patch and I look at the patch from #3129043: Move core database drivers to modules of their own, I come to the conclusion that that issue is more or less blocking getting https://www.drupal.org/project/pgsql_fallback to pass the testbot.

daffie’s picture

If we want core to enforce that, then let's open an issue for that. That would also imply that core's installer needs to enable the module if that's the selected driver.

Created #3129534: Automatically enable the module that is providing the current database driver. This issue will block the improvement of the BackendCompilerPass. We need it to test the new BackendCompilerPass stuff.

daffie’s picture

Various Views tests, such as Drupal\Tests\datetime\Kernel\Views\FilterDateTimeTest, fail because they end up using the views.date_sql service (which is MySQL-specific) instead of the pgsql.views.date_sql service. The reason they don't use the latter is because per BackendCompilerPass, that's based on $container->get('database')->driver(), which for the fallback driver is PgsqlFallback, so we'd need a service named PgsqlFallback.views.date_sql.

I think we should improve BackendCompilerPass to check for a service based on $container->get('database')->databaseType() if it can't find one based on $container->get('database')->driver().

Created #3130973: Make the backend overridable service discovery also check the database type for an overridden service for fixing the problem.

daffie’s picture

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

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

daffie’s picture

StatusFileSize
new5.2 KB

Rerolling the patch, because #3151118: Include bootstrap.inc using composer has landed.

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

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.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.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now 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.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now 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.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now 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: 10.1.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, which currently accepts only minor-version allowed changes. 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.