Deprecate removal of namespaced assets from schema

[morozov]

Q	A
Type	deprecation

Silently dropping database objects from the schema looks like a disservice. If the application declares certain schema objects, it means that it expects them to exist in the resulting schema, so it won't work properly if these objects don't exist.

It will be easier to spot such issues if the visitor drops a table (all the queries against it will fail) but the problems may be way harder to diagnose if a foreign key is dropped. This way, the application will rely on the referential integrity being preserved by the database but in fact it the database won't have the expected constraints in place.

According to the GH6823Test in the ORM, there is a flaw in this logic:

dbal/src/Schema/Visitor/RemoveNamespacedAssets.php

Lines 75 to 79 in 4be7e2f

	// The table may already be deleted in a previous
	// RemoveNamespacedAssets#acceptTable call. Removing Foreign keys that
	// point to nowhere.
	if (! $this->schema->hasTable($fkConstraint->getForeignTableName())) {
	$localTable->removeForeignKey($fkConstraint->getName());

The entities being deployed in the test don't declare a namespaced object name but the visitor drops a valid foreign key because the referenced entity (GH6823Tag) isn't being deployed as part of the schema.

The following statement is missing as a result of processing schema by the visitor:

ALTER TABLE gh6823_user_tags ADD FOREIGN KEY (tag_id) REFERENCES gh6823_tag (id)