We had a situation that migration is written beforesql_generate_invisible_primary_key was enabled and it was working ok, after this flag was enable one of the migration was failing with following error/warning:
This version of MySQL doesn't yet support 'existing primary key drop without adding a new primary key. In @@sql_generate_invisible_primary_key=ON mode table should have a primary key. Please add a new primary key to be able to drop existing primary key.'
Unfortunately this error is not stopping process of migration, as result: migration status is 100% (all executed) but database state does not match expected one.
Q
A
New Feature
yes
RFC
no
BC Break
no
Summary
This would be great to execute SHOW WARNING / SHOW ERROR after each stmt and abort if ERROR
^ array:1 [
0 => array:3 [
"Level" => "Error"
"Code" => 1235
"Message" => "This version of MySQL doesn't yet support 'existing primary key drop without adding a new primary key. In @@sql_generate_invisible_primary_key=ON mode table should have a primary key. Please add a new primary key to be able to drop existing primary key.'"
]
]
4afa65a65905:/app#
At the moment it's more MySQL-specific so it's not easy just execute SHOW WARNING because other engine may not have this syntax.
I see a needs of event system in \Doctrine\Migrations\Version\DbalExecutor::executeResult pre/post events, this way we could hook into post-event, execute MySQL specific code and throw error if needed without affecting other engines.
Feature Request
This is more MySQL specifc issue.
So since 8.0.30, MySQL has
sql_generate_invisible_primary_key
https://dev.mysql.com/doc/refman/8.0/en/create-table-gipks.html https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_sql_generate_invisible_primary_keyWe had a situation that migration is written before
sql_generate_invisible_primary_key
was enabled and it was working ok, after this flag was enable one of the migration was failing with following error/warning:Unfortunately this error is not stopping process of migration, as result: migration status is 100% (all executed) but database state does not match expected one.
Summary
This would be great to execute
SHOW WARNING
/SHOW ERROR
after each stmt and abort if ERRORAt the moment it's more MySQL-specific so it's not easy just execute
SHOW WARNING
because other engine may not have this syntax.I see a needs of event system in
\Doctrine\Migrations\Version\DbalExecutor::executeResult
pre/post events, this way we could hook into post-event, execute MySQL specific code and throw error if needed without affecting other engines.