This PR adds full support for foreign key constraints to Go La Tengo. This takes @chrisjpalmer's work from 2017 (thank you again Chris!), integrates some more recent refactoring that has happened in the package, adds support for a missing feature (multi-column foreign keys), and adds extensive test coverage.
Several other aspects of the package have been refactored in order to make this cleaner, as well as to solve the problem posed in #2.
Important note: by default, foreign key names are considered cosmetic, and simple renames (where no other aspect of an FK was changed) are ignored in diffs. This is to maximize compatibility with pt-online-schema-change, which needs to mangle FK names -- typically by prepending an underscore -- in order to function. To override this behavior and emit ALTER TABLE for renamed FKs anyway, use the new StatementModifiers field StrictForeignKeyNaming.
This PR adds full support for foreign key constraints to Go La Tengo. This takes @chrisjpalmer's work from 2017 (thank you again Chris!), integrates some more recent refactoring that has happened in the package, adds support for a missing feature (multi-column foreign keys), and adds extensive test coverage.
Several other aspects of the package have been refactored in order to make this cleaner, as well as to solve the problem posed in #2.
Important note: by default, foreign key names are considered cosmetic, and simple renames (where no other aspect of an FK was changed) are ignored in diffs. This is to maximize compatibility with pt-online-schema-change, which needs to mangle FK names -- typically by prepending an underscore -- in order to function. To override this behavior and emit ALTER TABLE for renamed FKs anyway, use the new StatementModifiers field StrictForeignKeyNaming.
Fixes #2.