5.5.2 Same actual data node cannot be configured in multiple logic tables in same database

[geekerzhou]

Bug Report

For English only, other languages will not accept.

Before report a bug, make sure you have:

• Searched open and closed GitHub issues.
• Read documentation: ShardingSphere Doc.

Please pay attention on issues you submitted, because we maybe need more details. If no response anymore and we cannot reproduce it on current information, we will close it.

Please answer these questions before submitting your issue. Thanks!

Which version of ShardingSphere did you use?

5.5.2

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

jdbc

Expected behavior

- !SHARDING
    tables:
      order_main:
        actualDataNodes: ds$->{0..2}.order_main_$->{0..999}
        databaseStrategy:
          standard:
            shardingColumn: order_id
            shardingAlgorithmName: custom-database-algorithm
        tableStrategy:
          standard:
            shardingColumn: order_id
            shardingAlgorithmName: custom-order-id-algorithm
      order_main_hint:
        actualDataNodes: ds$->{0..2}.order_main_$->{0..999}
        databaseStrategy:
          hint:
            shardingAlgorithmName: custom-hint-algorithm
        tableStrategy:
          hint:
            shardingAlgorithmName: custom-hint-algorithm

this config works fine in 5.2.1, upgrade to 5.5.2 throw exception

Actual behavior

Same actual data node cannot be configured in multiple logic tables in same database, logical table 'order_main_hint', actual data node 'ds0.order_main_0'.

Reason analyze (If you can)

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

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

[suummer]

Same. It doesn't work when upgrading from 5.5.0 to 5.5.2.

In my case, sharding.yml is configured like this:

 !SHARDING
  tables:
    mytable:
      actualDataNodes: >
        db.mytable_ext_${(0..1000000).step(500000)},
        db.mytable_${(0..1000000).step(500000)}
      tableStrategy:
          standard:
            shardingColumn:  tableid

It will work in 5.5.0, but 5.5.2 added SharindRuleChecker, which will test if the expression of 'actualDataNodes' is valid: set shardingColumn to 1 and caculate to get a data node's name, then check if the result is starts with table's prefix.

This is an easy way to verify correctness of actualDataNodes.

And the question is how to get the table's prefix? When creating tables' DataNodeInfo in ShardingTable, the first date node is used to get the table's prefix, so it will work if I simply change lines sequence:

      actualDataNodes: >
        db.mytable_${(0..1000000).step(500000)},
        db.mytable_ext_${(0..1000000).step(500000)}

It's kind of weird. It may be that the inspection method needs to be improved.

[yjmyzz]

同1个逻辑表，对应不同的实际表，在某些场景下是有用的。

比如：逻辑表t_shop，对应一堆shop_0,... shop_n，其中某些数据量大的商家，单独到某个特定的分表，比如shop_1

如果想快速查这些大商家的数据（又不知道id的情况下），可以单独映射1个新的逻辑表 big_shop -> shop_1

需要查询的地方，直接查big_shop就可以了