--no-database schema build fails with various module configuration

[maxime-rainville]

The schema builder tries to run a bunch of queries for the versions key on versionned DataObjects.

Normally, that's fine ... however if you're trying to build your schema with the NullDatabase, it's going to crash because Versionned::allVersions() always tries to run a bunch of queries.

I'm tempted to call this a bug with Versionned. But I'm not sure if it's indicative of a wider problem with GraphQL v4. There's a big catch statement on the Builder that was being triggered by this issue. That block prints out a warning saying "Your schema configuration requires access to the database", which implies that there might be a legitimate use case for being able to run queries when bulidng a schema.

silverstripe-graphql/src/Dev/Build.php

Lines 98 to 124 in e24dd87

	} catch (NullDatabaseException $e) {
	$candidate = null;
	foreach ($e->getTrace() as $item) {
	$class = $item['class'] ?? null;
	$function = $item['function'] ?? null;
	// This is the only known path to a database query, so we'll offer some help here.
	if ($class === FieldAccessor::class && $function === 'accessField') {
	$candidate = $item;
	break;
	}
	}
	$logger->warning("
	Your schema configuration requires access to the database. This can happen
	when you add fields that require type introspection (i.e. custom getters).
	It is recommended that you specify an explicit type when adding custom getters
	to your schema.");
	if ($candidate) {
	$logger->warning(sprintf(
	"
	This most likely happened when you tried to add the field '%s' to '%s'",
	$candidate['args'][1],
	get_class($candidate['args'][0])
	));
	}
	throw $e;
	}

Also, the logger on line 115 throws an error because the $candidate array is not in the expected format.

Pull requests

• Don't run queries when trying to retrieve versions for unsaved records silverstripe-versioned#352

[maxime-rainville]

Just did a bit more investigations. Even after we fix the Versionned problem, we're still seeing failures from Fluent, AkismetMiddleware and Subsites.

Those three modules could potentially break a dev/build because they want to run queries on every requests. They all have logic to try to detect if specific tables exists on the DB. To make things even more fun, they all use different combination of approaches:

• Security::database_is_ready()
• DataObjectSchema::classHasTable()
• ClassInfo::hasTable
• DBSchemaManager::hasTable()
• Catching a DatabaseException and selectively reading the message to see if a Database exists.

Even if we patch all of those to account for the NullDatabase use case, we'll probably end up breaking other people code.

[GuySartorelli]

@maxime-rainville That reminds me about silverstripe/silverstripe-framework#10041 - if that PR would be useful to help clean this up let me know and I'll take a look at seeing what went wrong with those tests.