-
Dmitry Lenev authored
After we have started to store information about foreign keys in the New Data Dictionary it became possible to move checks of foreign key definition validity from the storage engine to SQL-layer and thus reduce code duplication and simplify SE implementation. This patch moves check that disallows dropping of parent table in a foreign key without prior dropping of child table from InnoDB SE to SQL-layer code implementing DROP TABLES/DROP DATABASE. Such check now happens before trying to delete any tables mentioned in DROP TABLES statement/belonging to schema to be dropped. So DROP TABLES/DROP DATABASE no longer have any side-effect even on tables in SEs which don't support atomic DDL when they fail due to this check. The check was also relaxed to allow dropping of parent and child table in arbitrary order as long as they are dropped by the same DROP TABLES statement. This is possible thanks to the fact that both our engines supporting foreign keys also support atomic DDL. Finally, error message which is emitted when user attempts to drop parent table without dropping child was changed to more verbose one. New test coverage for this check was added and existing tests were adjusted accordingly. Also, some test cases which previously used foreign key dependency as a way to fail DROP TABLES/DATABASE in the middle of their execution had to be adjusted to rely on error injection instead.
Dmitry Lenev authoredAfter we have started to store information about foreign keys in the New Data Dictionary it became possible to move checks of foreign key definition validity from the storage engine to SQL-layer and thus reduce code duplication and simplify SE implementation. This patch moves check that disallows dropping of parent table in a foreign key without prior dropping of child table from InnoDB SE to SQL-layer code implementing DROP TABLES/DROP DATABASE. Such check now happens before trying to delete any tables mentioned in DROP TABLES statement/belonging to schema to be dropped. So DROP TABLES/DROP DATABASE no longer have any side-effect even on tables in SEs which don't support atomic DDL when they fail due to this check. The check was also relaxed to allow dropping of parent and child table in arbitrary order as long as they are dropped by the same DROP TABLES statement. This is possible thanks to the fact that both our engines supporting foreign keys also support atomic DDL. Finally, error message which is emitted when user attempts to drop parent table without dropping child was changed to more verbose one. New test coverage for this check was added and existing tests were adjusted accordingly. Also, some test cases which previously used foreign key dependency as a way to fail DROP TABLES/DATABASE in the middle of their execution had to be adjusted to rely on error injection instead.
Loading