When a table has a composite key, precise and regex search-replace fails because of a SQL syntax error.
Once the cause of the SQL syntax error was addressed, there was another bug where, for a composite key (X, Y, Z) the next batch conditions were always X > lastX AND Y > lastY AND Z > lastZ. This condition can skip rows when ordering by X, Y, and Z because Y and Z may repeat values within different values of X. If we assume Y and Z always increase independently of one another, we will skip rows where previous Y and Z values repeat under subsequent values of X.
There are three commits under this PR. The first adds tests that will fail until the next two commits are applied. Please note that number of rows INSERTed for testing with composite primary keys is intentionally different than the number of rows used to test with single primary keys. The idea is to avoid symmetry to reduce the likelihood of the total count accidentally matching due to some other bug (e.g., a bug where composite key rows aren't replaced at all but single key rows are counted twice).
Perhaps it would be good to separate single key and composite key into dedicated scenarios, but so far, I have simply updated the precise and regex batch scenarios to also test with composite primary keys.
To test:
Check out this branch
git revert --no-commit HEAD HEAD~1 to temporarily reverse both fixes
Run composer test and observe the failures due to SQL syntax errors
Restore branch with git revert --abort
git revert --no-commit HEAD to temporarily reverse the second fix
Run composer test and observe that the total number of replacements is 3000 rather than the expected total of 4050.
Fixes #182
This PR addresses two bugs:
There are three commits under this PR. The first adds tests that will fail until the next two commits are applied. Please note that number of rows INSERTed for testing with composite primary keys is intentionally different than the number of rows used to test with single primary keys. The idea is to avoid symmetry to reduce the likelihood of the total count accidentally matching due to some other bug (e.g., a bug where composite key rows aren't replaced at all but single key rows are counted twice).
Perhaps it would be good to separate single key and composite key into dedicated scenarios, but so far, I have simply updated the precise and regex batch scenarios to also test with composite primary keys.
To test:
git revert --no-commit HEAD HEAD~1
to temporarily reverse both fixescomposer test
and observe the failures due to SQL syntax errorsgit revert --abort
git revert --no-commit HEAD
to temporarily reverse the second fixcomposer test
and observe that the total number of replacements is 3000 rather than the expected total of 4050.git revert --abort
composer test
and note that all tests pass