Some SQL is always created by the diff command for columns using setColumnDefinition

[danrot]

Bug Report

Q	A
BC Break	no
Version	3.9.4

Summary

I have a column for the last update in a table, for which I have set a column definition. Now it seems like because of that column definition some SQL in the migrations is generated when using the doctrine:migrations:diff command, even if the database schema is already in the correct state.

Current behavior

New migration SQL is created even if there should be no changes. At least that's what's happening when using MySQL 5.7.

How to reproduce

1. Create a custom schema with a column definition like the following:

$table->addColumn(
	Column::editor()
		->setUnquotedName('updated_at')
		->setTypeName('datetime')
		->setColumnDefinition('DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP NOT NULL')
		->create(),
);

2. Run the bin/console doctrine:migrations:diff command
3. Update your database schema using bin/console doctrine:migrations:migrate
4. Run the bin/console doctrine:migrations:diff command again
5. You'll end up with two migrations, whereby the second contains a line like the following:

ALTER TABLE table CHANGE updated_at updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP NOT NULL

Expected behavior

After the previous steps there should only be one migrations file, because there are no changes to apply.

[stof]

using columnDefinition is known to cause issue with the schema comparator of DBAL, as it is a way to bypass the actual schema handling of DBAL (and so the comparator might not be able to compare things)

[danrot]

@stof Thank you, good to know! But at the same time this is the only workaround I found to make the ON UPDATE CURRENT_TIMESTAMP part work 🙈 Is there a better way to achieve this, without causing the issue of getting the same migrations for every diff?