Deprecate ignoring foreign keys DDL on non-InnoDB MySQL #5414
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm working on replacing
CreateSchemaSqlCollector
andDropSchemaSqlCollector
with another set of SQL builders to enable seamless support for foreign keys on SQLite (see #5409 (comment)).There will be a new platform method that will generate SQL to create a set of tables that may reference each other via foreign keys at once.
The default implementation in the
AbstractPlatform
class will first create all tables without foreign keys and then create all foreign keys. This way, the foreign key dependencies will be satisfied at every step of the migration.The implementation for the SQLite platform will just create the tables with the foreign keys because:
In order to support the feature being deprecated, I'll have to create another implementation of the above method for MySQL which would ignore foreign keys in the new method if the target engine will ignore them.
While it's not a big deal, I believe this functionality is pointless: if the application that owns the schema doesn't require the support for foreign keys across all target platforms and storage engines, it should enforce referential integrity itself, at which point it won't require it enforced by the database platform. If it does need them, it should use only the platforms and the engines that support them.