You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using Symfony 7.2 and its Maker bundle. Under the hood the make:migration command calls doctrine:migrations:diff. For some reason, it keeps dropping and re-adding foreign keys on totally unrelated entities.
I'm using MariaDB 11.2.2 on this machine.
Current behavior
doctrine:migrations:diff drops and re-adds unrelated foreign keys (see steps to reproduce).
How to reproduce
Either use make:entity in Symfony or add this entity manually:
Run doctrine:migrations:diff --formatted. I'm getting this:
<?phpdeclare(strict_types=1);
namespaceDoctrineMigrations;
useDoctrine\DBAL\Schema\Schema;
useDoctrine\Migrations\AbstractMigration;
finalclass Version20250109223941 extends AbstractMigration
{
publicfunctiongetDescription(): string
{
return'Created languages table';
}
publicfunctionup(Schema$schema): void
{
$this->addSql('CREATE TABLE languages ( id INT AUTO_INCREMENT NOT NULL, position SMALLINT UNSIGNED NOT NULL, code VARCHAR(20) NOT NULL, english_name VARCHAR(100) NOT NULL, native_name VARCHAR(100) NOT NULL, PRIMARY KEY(id) ) DEFAULT CHARACTER SET utf8mb4 COLLATE `utf8mb4_unicode_ci` ENGINE = InnoDB');
$this->addSql('ALTER TABLE reset_password_request DROP FOREIGN KEY FK_7CE748AA76ED395');
$this->addSql('ALTER TABLE reset_password_request ADD CONSTRAINT FK_7CE748AA76ED395 FOREIGN KEY (user_id) REFERENCES users (id)');
}
publicfunctiondown(Schema$schema): void
{
// this down() migration is auto-generated, please modify it to your needs$this->addSql('DROP TABLE languages');
$this->addSql('ALTER TABLE reset_password_request DROP FOREIGN KEY FK_7CE748AA76ED395');
$this->addSql('ALTER TABLE reset_password_request ADD CONSTRAINT FK_7CE748AA76ED395 FOREIGN KEY (user_id) REFERENCES users (id) ON DELETE CASCADE');
}
}
the reset_password_request migration for reference:
<?phpdeclare(strict_types=1);
namespaceDoctrineMigrations;
useDoctrine\DBAL\Schema\Schema;
useDoctrine\Migrations\AbstractMigration;
finalclass Version20250101232946 extends AbstractMigration
{
publicfunctiongetDescription(): string
{
return'Added the reset password request table and isVerified column to the Users table';
}
publicfunctionup(Schema$schema): void
{
$this->addSql(
'CREATE TABLE reset_password_request ( id INT AUTO_INCREMENT NOT NULL, user_id INT NOT NULL, selector VARCHAR(20) NOT NULL, hashed_token VARCHAR(100) NOT NULL, requested_at DATETIME NOT NULL COMMENT \'(DC2Type:datetime_immutable)\', expires_at DATETIME NOT NULL COMMENT \'(DC2Type:datetime_immutable)\', INDEX IDX_7CE748AA76ED395 (user_id), PRIMARY KEY(id) ) DEFAULT CHARACTER SET utf8mb4 COLLATE `utf8mb4_unicode_ci` ENGINE = InnoDB');
$this->addSql(
'ALTER TABLE reset_password_request ADD CONSTRAINT FK_7CE748AA76ED395 FOREIGN KEY (user_id) REFERENCES users (id) ON DELETE CASCADE');
$this->addSql('ALTER TABLE users ADD is_verified TINYINT(1) NOT NULL');
}
publicfunctiondown(Schema$schema): void
{
$this->addSql('ALTER TABLE reset_password_request DROP FOREIGN KEY FK_7CE748AA76ED395');
$this->addSql('DROP TABLE reset_password_request');
$this->addSql('ALTER TABLE users DROP is_verified');
}
}
Expected behavior
The reset_password_request table has nothing to do with this one at all, so it shouldn't be altered. There is no relations to users table either, it's just a standalone languages table.
The text was updated successfully, but these errors were encountered:
Bug Report
Summary
I'm using Symfony 7.2 and its Maker bundle. Under the hood the
make:migration
command callsdoctrine:migrations:diff
. For some reason, it keeps dropping and re-adding foreign keys on totally unrelated entities.I'm using MariaDB 11.2.2 on this machine.
Current behavior
doctrine:migrations:diff
drops and re-adds unrelated foreign keys (see steps to reproduce).How to reproduce
make:entity
in Symfony or add this entity manually:doctrine:migrations:diff --formatted
. I'm getting this:the
reset_password_request
migration for reference:Expected behavior
The
reset_password_request
table has nothing to do with this one at all, so it shouldn't be altered. There is no relations tousers
table either, it's just a standalonelanguages
table.The text was updated successfully, but these errors were encountered: