EntityQueryTest::testToString fails with non-core db drivers

I am working on a full support database driver for MongoDB (https://gitlab.com/daffie/drumongous and https://gitlab.com/daffie/mongodb). And MongoDB does not do SQL. For me this issue is a absolute need.
The patch looks good to me. To RTBC.

@daffie how is this patch an absolute need? How are you choosing which core tests to run? Maybe a better solution than hardcoding driver names is to make this a different test.

"Absolute need" is maybe a little bit to much, but MongoDB does not do SQL strings. Also the way entities are stored in MongoDB is different, so the resulting query will be different. The test-result for a MongoDB database driver will be different. Maybe we should only run the test for relational databases. @alexpott: If you have a better idea, then please say so. Better ideas are always welcome. :)

@daffie well what we should do here is identify tests that a custom/contrib driver should run - how are we currently identifying them? I don't think we are at all and I don't think it is realistic to say run all the tests in core. There's going to be more than this one that fails for good reasons on a MongoDB database driver.

There's going to be more than this one that fails for good reasons on a MongoDB database driver.

@alexpott: You are absolutly right. It is just that @mondrake created this issue and it is part of the problem with support in core for contrib database drivers/extensions.
A number of contributers like to work on extending the database abstraction layer with more capabilities and others (like me) like to work on contrib database drivers for other then the by core supported databases.
In the ideas queue we have an issue for that and I have proposed a plan how to add support for contrib database drivers/extensions in core. See #2846366-17: Improve Drupal's Database Abstraction Layer Extensibility and Capabilities.
In a later stage we could create a system where contrib database driver/extensions can override core tests with there own implementation for specific tests. In that way core tests stay clean of contrib specific exceptions.

+++ b/core/tests/Drupal/KernelTests/Core/Entity/EntityQueryTest.php
@@ -1205,6 +1206,10 @@ public function testConditionOnRevisionMetadataKeys() {
+    if (!in_array(Database::getConnection()->driver(), ['mysql', 'sqlite', 'pgsql'])) {
+      $this->markTestSkipped("This test only runs for Drupal core database drivers");
+    }

So i'm not really a fan of this. It feels fragile. Imagine we add a mariadb specific driver to core.

I think we need to back to the drawing board and come up with a less fragile way of producing a test suite for contrib / custom db drivers.

As we can never know ahead of time which tests are going to be problematic for custom database drivers, should the driver itself be responsible for declaring a list of test classes (or perhaps methods) that should be skipped when running the full test suite? The driver can then provide its own version of those skipped tests if they need modifying to run on that driver.

A typical solution for what @alexpott wants will result in a system with hooks or plugins. Both require that the custom database driver has module like capabilities.

@daffie I don't think it does. I think it involves tagging tests and test methods with additional @group so that we can agree what tests/methods need to be db agnostic and provide a good coverage for a contrib / custom db driver. Or we can go the other way... and add a group to tests we know are SQL database specific and then contrib / custom drivers can use --exclude-group.

I like the new approach.
It all looks good to me.
It is all very good documented.
It should also work for contrib database drivers.
For me it is RTBC.

Committed and pushed deaf132106 to 9.0.x and b0b039da19 to 8.9.x. Thanks!

Doesn't merge to 8.8.x so I've not bothered backporting.