Bug Report
Which version of ShardingSphere did you use?
master @ 80e6541
Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy?
Both (kernel-level)
Expected behavior
When ALTER ENCRYPT RULE removes a column's assisted-query or like-query, the auto-generated encryptors backing them should be dropped from the persisted configuration, leaving no orphaned encryptors.
Actual behavior
The auto-generated assist_* / like_* encryptors stay in the persisted configuration as orphans after the columns referencing them are removed by ALTER.
Reason analyze (If you can)
AlterEncryptRuleExecutor.buildToBeDroppedRuleConfiguration() ignores its toBeAlteredRuleConfig parameter and runs UnusedAlgorithmFinder.findUnusedEncryptor(rule.getConfiguration()) against the pre-alter configuration. There every encryptor is still referenced, so the finder always returns empty and nothing is dropped. The sibling AlterMaskRuleExecutor already computes the post-alter in-use set correctly, and DropEncryptRuleExecutor is also correct; only the ALTER encrypt path is broken.
Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.
Create an encrypt rule on a column with assisted-query and like-query, then ALTER ENCRYPT RULE the same column keeping only the cipher. The assist_* / like_* encryptors remain in the persisted rule.
Example codes for reproduce this issue (such as a github link).
N/A
Bug Report
Which version of ShardingSphere did you use?
master @ 80e6541
Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy?
Both (kernel-level)
Expected behavior
When
ALTER ENCRYPT RULEremoves a column's assisted-query or like-query, the auto-generated encryptors backing them should be dropped from the persisted configuration, leaving no orphaned encryptors.Actual behavior
The auto-generated
assist_*/like_*encryptors stay in the persisted configuration as orphans after the columns referencing them are removed by ALTER.Reason analyze (If you can)
AlterEncryptRuleExecutor.buildToBeDroppedRuleConfiguration()ignores itstoBeAlteredRuleConfigparameter and runsUnusedAlgorithmFinder.findUnusedEncryptor(rule.getConfiguration())against the pre-alter configuration. There every encryptor is still referenced, so the finder always returns empty and nothing is dropped. The siblingAlterMaskRuleExecutoralready computes the post-alter in-use set correctly, andDropEncryptRuleExecutoris also correct; only the ALTER encrypt path is broken.Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.
Create an encrypt rule on a column with assisted-query and like-query, then
ALTER ENCRYPT RULEthe same column keeping only the cipher. Theassist_*/like_*encryptors remain in the persisted rule.Example codes for reproduce this issue (such as a github link).
N/A