fix: add missing drop schema when dropping database

[nikophil]

Q	A
Type	bug
Fixed issues	doctrine/orm#11701

Summary

fixes doctrine/orm#11701 which was actually a dbal issue.

When we'll be OK with the implementation, I'll provide another PR to fix this in dbal 3

[nikophil]

not sure what to do with the "main" public schema, I don't know if this is specific to PG or not.

In PG, this schema is automatically created when the db is created, so I don't think we should drop it with doctrine:schema:drop

[SenseException]

Good question. Schemas can have different permissions in newer PostgreSQL versions and removing the defult public would also remove those with it, as it would with the custom schemas. I guess I'd expect it to be removed too when I want to drop schemas. 🤔

[nikophil]

ok, I've removed the exception for the public schema

[nikophil]

Since I have removed the exception for public schema, I got an error in PostgreSQLSchemaManagerTest::testDropWithAutoincrement():

Doctrine\DBAL\Driver\PgSQL\Exception: cannot drop schema public because other objects depend on it

in PostgreSQLSchemaManagerTest.php:364

And given this comment, I think we will have problems dropping schemas which contains views, and schema "that need to be quoted".

I'm wondering if we can mitigate these problems:

• schema which contains view: shouldn't we drop views as well in DropSchemaObjectsSQLBuilder (because we don't refer to views in \Doctrine\DBAL\Schema\Schema, this seems a little bit complicated, but we can pass a list of the views to DropSchemaObjectsSQLBuilder)
• schemas that need to be quoted: in AbstractAsset::getQuotedName(), maybe we can also check if the asset's name starts with an integer? Or if this rule is dependent of the current platform, we could add a method for this in AbstractPlatform?

WDYT?

[nikophil]

hi @SenseException @greg0ire , any chance to have some insights about this please? thanks! 🙏 🙏

[morozov]

It looks like in order to correctly drop the schemas containing views, we need to implement introspection of the views in the schema.

The following is not by design, it was just never implemented.

dbal/tests/Functional/Schema/PostgreSQLSchemaManagerTest.php

Lines 341 to 343 in c91166a

	* 2. The schema returned by {@see AbstractSchemaManager::introspectSchema()} doesn't contain views, so
	* {@see AbstractSchemaManager::dropSchemaObjects()} cannot drop the tables that have dependent views
	* (@see testListTablesExcludesViews()).

[morozov]

dbal/tests/Functional/Schema/PostgreSQLSchemaManagerTest.php

Lines 339 to 340 in c91166a

	* 1. The DBAL currently doesn't properly drop tables in the namespaces that need to be quoted
	* (@see testListTableDetailsWhenCurrentSchemaNameQuoted()).

I don't remember what exactly the problem is. Quoting names that start with a digit is a workaround. I don't think it's a strict requirement if your code will be unable to drop such schemas as long as it doesn't introduce new problems. The issues with quoted names need to be fixed separately.

[nikophil]

yes, I was planning to fix both problems in separate PRs, thanks for your hints!

[nikophil]

@morozov I wanted this PR to be a fix, but implementing introspection of the views in the schema feels like a total new feature... WDYT? (For now I've made it here, but I can move it in another PR)

[SenseException]

It seems that codecov found some uncovered code paths that need to be addressed in separate tests.

[nikophil]

Hi @SenseException, thanks for your review

It seems that codecov found some uncovered code paths that need to be addressed in separate tests.

super weird, the places where codcov has added annotations are covered by the new test 🤔

If I add dumps in the code, when running this command, I can see it is covered

vendor/bin/phpunit --filter testDropWithSchema -c pgsql.phpunit.xml

[greg0ire]

I believe this is caused by codecov/codecov-action#1580
Right now, we get coverage data, but only based on appveyor and not Github 😢

I'm assuming that @SenseException was refering to a passing build, because the codecov upload job does not even run when one of the github job fails like it's the case right now.