Sharding constraint reviser removes every actual table suffix occurrence from constraint names

Bug Report

Which version of ShardingSphere did you use?

master @ 101c3d56ccd

Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy?

Both

Expected behavior

When a sharding table's actual constraint name is <logicName>_<actualTable>, the loaded logic constraint name is <logicName>, with only the trailing _<actualTable> suffix removed.

Actual behavior

Every occurrence of _<actualTable> is removed. With database-only sharding (actual table name equals logic name), the stored FK fk_t_order_item_order_t_order_item is loaded back as fk_order instead of fk_t_order_item_order. MySQLShardingShowCreateTableMergedResult.replaceConstraints() then looks for fk_order_t_order_item, so SHOW CREATE TABLE keeps the actual FK name unreplaced.

Reason analyze (If you can)

ShardingConstraintReviser.getLogicIndex() (features/sharding/core, line 53) checks endsWith(suffix) but strips with String.replace(suffix, ""), which removes all occurrences. The producer ConstraintToken.getConstraintValue() appends '_' + actualTable once, and the sibling ShardingIndexReviser relies on IndexMetaDataUtils.stripActualIndexNameSuffix(), which removes only the tail.

Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.

1. Configure t_order_item with actualDataNodes: ds_${0..1}.t_order_item.
2. CREATE TABLE t_order_item (order_id BIGINT, CONSTRAINT fk_t_order_item_order FOREIGN KEY (order_id) REFERENCES t_order (order_id)).
3. Reload metadata, then SHOW CREATE TABLE t_order_item.

Expected: fk_t_order_item_order. Actual: fk_t_order_item_order_t_order_item.

Example codes for reproduce this issue (such as a github link).

N/A