-
Notifications
You must be signed in to change notification settings - Fork 331
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Allow proper filtering with --where in parent-child relationships #885
base: 3.x
Are you sure you want to change the base?
Conversation
1b6e8e3
to
fcd17c0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a test case.
I would appreciate it if you could run the CI to confirm that everything is working correctly. :) |
Thank you for the update. There are instructions how to run tests in CONTRIBUTING.md I myself run following snippet:
Replace paths to relevant for your system. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my case, test fails when tries to load t/pt-online-schema-change/samples/basic_with_fks_diff_ids.sql:
$ ptmaster < t/pt-online-schema-change/samples/basic_with_fks_diff_ids.sql
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1054 (42S22) at line 45: Unknown column 'city_id' in 'field list'
Please correct this SQL file.
Problem Description:
When using the --where filter in pt-online-schema-change, an error occurs when the filter is applied to a parent table (e.g., city), and the tool attempts to propagate changes to related child tables (e.g., address). Specifically, the --where condition is applied to the parent table, but the tool erroneously tries to apply this filter to child tables that do not contain the referenced column. This causes an error, as the columns in the child tables do not exist, leading to a failure during the operation.
The issue arises because pt-online-schema-change tries to apply the filter to the child tables, where the column being referenced in the --where condition (e.g., status in city) does not exist. This behavior prevents the tool from successfully executing the change and results in the error, particularly in relationships with foreign keys between the tables.
Example SQL:
In this example, the tables city and address are related via a foreign key (city_id in address referencing id in city). If a --where filter is applied to the city table, pt-online-schema-change might incorrectly attempt to apply this filter to the address table as well, causing an error because the status column (referenced in the --where condition) does not exist in the child table.
Note: Unfortunately, I was unable to run the tests locally, so I have not included any test commits with this pull request. If this issue doesn't seem relevant, could you please provide guidance on resolving this locally so that I can run the tests correctly?