Table in default schema is recreated (when the schema is specified)

[zerkms]

Bug Report

Q	A
BC Break	no
Version	3.2.1

Summary

If a schema is explicitly specified - the table is recreated every migration:

    <entity name="Db\Schema\Dummy" table="dummy" schema="public">
        <id name="id" type="integer">
            <generator strategy="IDENTITY" />
        </id>
    </entity>

This generates this initial migration:

final class Version20210829230256 extends AbstractMigration
{
    public function getDescription(): string
    {
        return '';
    }

    public function up(Schema $schema): void
    {
        // this up() migration is auto-generated, please modify it to your needs
        $this->addSql('CREATE TABLE public.dummy (id SERIAL NOT NULL, PRIMARY KEY(id))');
    }

    public function down(Schema $schema): void
    {
        // this down() migration is auto-generated, please modify it to your needs
        $this->addSql('DROP TABLE public.dummy');
    }
}

Then I apply the migration and run diff once again, and it generates the following migration

final class Version20210829230310 extends AbstractMigration
{
    public function getDescription(): string
    {
        return '';
    }

    public function up(Schema $schema): void
    {
        // this up() migration is auto-generated, please modify it to your needs
        $this->addSql('CREATE TABLE public.dummy (id SERIAL NOT NULL, PRIMARY KEY(id))');
        $this->addSql('DROP TABLE dummy');
    }

    public function down(Schema $schema): void
    {
        // this down() migration is auto-generated, please modify it to your needs
        $this->addSql('CREATE TABLE dummy (id SERIAL NOT NULL, PRIMARY KEY(id))');
        $this->addSql('DROP TABLE public.dummy');
    }
}

From the other hand - if I don't specify the schema explicitly the second diff generates

final class Version20210829230712 extends AbstractMigration
{
    public function getDescription(): string
    {
        return '';
    }

    public function up(Schema $schema): void
    {
        // this up() migration is auto-generated, please modify it to your needs

    }

    public function down(Schema $schema): void
    {
        // this down() migration is auto-generated, please modify it to your needs
        $this->addSql('CREATE SCHEMA public');
    }
}

which is also wrong as it should not recreate the public schema.

Current behavior

How to reproduce

Expected behavior

It should not try to recreate a table given it has not changed.

[tomasnorre]

I can confirm this.

Reported it in Symfony as I thought it was a Symfony component. https://github.com/symfony/symfony/issues/44952

[ghost]

I can also confirm this behaviour. In a current project running with Symfony 6.0.1 on PHP 8.1.0, Debian 10 x64 system I keep extending Doctrine Entities created with make:entity by hand. Whenever I run make:migration I have to manually remove the CREATE SCHEMA statement from generated migration. The schema name was configured in database url as follows:

postgresql://symfony:[email protected]:5432/techdb_dev?serverVersion=13&charset=utf8&schema=test

Interesting about this: The schema name gets ignored completely. It always adds "CREATE SCHEMA public" to the down method of the migration. So I decided to remove the schema from my database url, anyway Doctrine keeps adding it to my migrations.

[pkly]

I also encountered this, but for me it's the ALTER instructions, as we already had an existing schema on older versions.

My whole down() method in the migration is basically changing all fields to be "themselves" again, even if the migration itself only changes one or two, all tables are changed "back" (to what they already are).

In my case only 3 fields changed (new comment, migration from guid to uuid), and I got 12 lines modifying all entities and all of their fields, not only the changed ones. And my schema is on the entity as PHP attributes

[allan-simon]

I found the root issue and opened a PR https://github.com/doctrine/dbal/pull/5600 with full explanation here https://github.com/doctrine/dbal/issues/5609