fix: Allow proper filtering with --where in parent-child relationships

[antoniocunh]

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:

CREATE TABLE `city` (
  `id` smallint(5) unsigned NOT NULL AUTO_INCREMENT,
  `city` varchar(50) NOT NULL,
  `country_id` smallint(5) unsigned NOT NULL,
  `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),  -- corrected from `city_id` to `id`
  KEY `idx_fk_country_id` (`country_id`),
  CONSTRAINT `fk_city_country` FOREIGN KEY (`country_id`) REFERENCES `country` (`country_id`) ON UPDATE CASCADE
) ENGINE=InnoDB;

CREATE TABLE `address` (
  `id` smallint(5) unsigned NOT NULL AUTO_INCREMENT,
  `address` varchar(50) NOT NULL,
  `city_id` smallint(5) unsigned NOT NULL,
  `postal_code` varchar(10) DEFAULT NULL,
  `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),  -- corrected from `address_id` to `id`
  KEY `idx_fk_city_id` (`city_id`),
  CONSTRAINT `fk_address_city` FOREIGN KEY (`city_id`) REFERENCES `city` (`id`) ON UPDATE CASCADE  -- corrected to reference `id` in `city`
) ENGINE=InnoDB;

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?

• The contributed code is licensed under GPL v2.0
• Contributor Licence Agreement (CLA) is signed
• util/update-modules has been ran
• Documentation updated
• Test suite update

[it-percona-cla]

All committers have signed the CLA.

[svetasmirnova]

Please add a test case.

[antoniocunh]

I would appreciate it if you could run the CI to confirm that everything is working correctly. :)