Open LeonidasJP opened 8 months ago
When dumping both schemas in Doctrine\Migrations\Generator\DiffGenerator::generate()
, @ line 91 just after both schemas have been generated, I am presented with the following _options
arrays on the TestEntity table
From schema:
Schema > _tables > anonymize.test_entity (instanceof DBAL\Schema\Table)
#_options: array:6 [
"create_options" => []
"engine" => "InnoDB"
"collation" => "utf8mb4_unicode_ci"
"charset" => "utf8mb4"
"autoincrement" => null
"comment" => ""
]
To schema:
Schema > _tables > anonymize.test_entity (instanceof DBAL\Schema\Table)
#_options: array:3 [
"create_options" => []
"charset" => "utf8mb4"
"comment" => "Testcomment"
]
So, the DBAL Schema gets updated. But, Doctrine\DBAL\Schema\TableDiff
seems to be unable to detect changes on tables other than renames, columns, indexes and foreign keys...
Are you able to reproduce this issue by using DBAL APIs only?
Yes. DBAL is not producing the diff for an updated table comment, and it seems TableDiff has no ability to handle them.
I am currently away from my PC and thus unable to generate a DBAL Only example.
Same issue here
Bug Report
Summary
I am working on an anonymizer-tool, that works with table- and column based comments. That way the anonymizer can run plainly with DBAL, without the tool needing access to project-specific files. Therefore, I need to be able to update a table comment.
Current behaviour
DBAL is detecting a comment that is being set on a new table, and also notices the changes on a column correctly. But updating the comment on an existing table is not being detected, and leads to a "No changes detected in your mapping information." when running
(symfony) bin/console doctrine:migrations:diff
, even when there are changes to the table comment.How to reproduce
(symfony) bin/console doctrine:migrations:diff && bin/console doctrine:migrations:migrate
(symfony) bin/console doctrine:migrations:diff
Expected behaviour
At least, I expect DBAL to detect the comment being updated. Preferably, I even would like Migrations to actually write the migration query necessary