Fix parsing of the foreign key constraint actions in different order #10224
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
On a FOREIGN KEY one can defined an action ON UPDATE and ON DELETE. The parser would only allow one specific order where first the ON DELETE is specified and then the ON UPDATE. This meant that a query which had it in the reverse order would fail to parse. This also allows bypassing the check on DDL statements that add a foreign key constraint too. Additionally, we move the schemadiff logic here to be strict for parsing. It was blowing up with a panic on a schema with such a differently ordered foreign key constraint but it should have error on any parser error. In case schemadiff can't parse something, we can't trust it to do any further operations on the schema. Signed-off-by: Dirkjan Bussink <d.bussink@gmail.com>
Review ChecklistHello reviewers! 👋 Please follow this checklist when reviewing this Pull Request. General
Bug fixes
Non-trivial changes
New/Existing features
Backward compatibility
|
dbussink
commented
May 5, 2022
| constraint second_ibfk_1 foreign key (k, j) references simple (a, b) on update no action, | ||
| constraint second_ibfk_1 foreign key (k, j) references simple (a, b) on update cascade | ||
| )`, | ||
| output: `create table t ( |
There was a problem hiding this comment.
This specific output was needed since the parser parses the actions into a struct so the ordering specifically of this is lost.
We have verified though that MySQL doesn't accidentally allows a list of these items, just only both orders so there's no potential semantic difference due to the different order.
GuptaManan100
approved these changes
May 5, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
On a
FOREIGN KEYone can defined an actionON UPDATEandON DELETE. The parser would only allow one specific order where first theON DELETEis specified and then theON UPDATE.This meant that a query which had it in the reverse order would fail to parse. This also allows bypassing the check on DDL statements that add a foreign key constraint too.
Additionally, we move the
schemadifflogic here to be strict for parsing. It was blowing up with a panic on a schema with such a differently ordered foreign key constraint but it should have error on any parser error.In case
schemadiffcan't parse something, we can't trust it to do any further operations on the schema.Related Issue(s)
schemadiffwork from schemadiff: tracking issue #10203Checklist