wsm12138 opened a new issue, #20071: URL: https://github.com/apache/shardingsphere/issues/20071
## Bug Report **For English only**, other languages will not accept. Before report a bug, make sure you have: - Searched open and closed [GitHub issues](https://github.com/apache/shardingsphere/issues). - Read documentation: [ShardingSphere Doc](https://shardingsphere.apache.org/document/current/en/overview). 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? ``` ShardingSphere-5.1.3-SNAPSHOT Commit ID: 9dd0d3990c849d50c17c6dc7c92ec2d4ce0ad7e5 ``` ### Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy? ` ShardingSphere-Proxy ` ### Expected behavior 1. show tables; have two table t_order_0;t_order_1. 2. drop table success 3. when exectue `drop table` ,it shoud have logs in stdout.log. because `sql-show: true` ### Actual behavior ``` sharding_db=> \d List of relations Schema | Name | Type | Owner | Storage --------+-----------+-------+---------+---------------------------------- public | t_order_1 | table | gaussdb | {orientation=row,compression=no} (1 row) sharding_db=> drop table t_order_1; ERROR: Table 't_order_1' doesn't exist sharding_db=> ``` ### Reason analyze (If you can) I think `t_order_1` shoud be treated as a single table, although the table is a part of `sharding_rule`; Maybe we can give table a role like(single,sharding),and save this information into zk or others? ##### table in ds0 & ds1 <img width="759" alt="image" src="https://user-images.githubusercontent.com/86462784/184062211-65423cf6-f1d5-474a-a68b-79053fca9345.png"> ##### ds & table & rules in Proxy <img width="1814" alt="image" src="https://user-images.githubusercontent.com/86462784/184062513-4fa8f9fb-49ff-40cf-8883-395ded3bd6e3.png"> ### 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). ``` databaseName: sharding_db # dataSources: ds_0: url: jdbc:opengauss://192.168.10.21:5432/demo_ds_0?batchMode=on username: gaussdb password: sphereEx@2021 connectionTimeoutMilliseconds: 30000 idleTimeoutMilliseconds: 60000 maxLifetimeMilliseconds: 1800000 maxPoolSize: 50 minPoolSize: 1 ds_1: url: jdbc:opengauss://192.168.10.21:5432/demo_ds_1?batchMode=on username: gaussdb password: sphereEx@2021 connectionTimeoutMilliseconds: 30000 idleTimeoutMilliseconds: 60000 maxLifetimeMilliseconds: 1800000 maxPoolSize: 50 minPoolSize: 1 rules: - !SHARDING tables: t_order: actualDataNodes: ds_${0..1}.t_order_${0..1} tableStrategy: standard: shardingColumn: order_id shardingAlgorithmName: t_order_inline keyGenerateStrategy: column: order_id keyGeneratorName: snowflake t_order_view: actualDataNodes: ds_${0..1}.t_order_view_${0..1} tableStrategy: standard: shardingColumn: order_id shardingAlgorithmName: t_order_view_inline t_order_view2: actualDataNodes: ds_${0..1}.t_order_view2_${0..1} tableStrategy: standard: shardingColumn: order_id shardingAlgorithmName: t_order_view2_inline t_item: actualDataNodes: ds_${0..1}.t_item_${0..1} tableStrategy: standard: shardingColumn: id shardingAlgorithmName: t_item_inline keyGenerateStrategy: column: order_id keyGeneratorName: snowflake bindingTables: - t_order,t_order_view,t_order_view2 defaultDatabaseStrategy: standard: shardingColumn: user_id shardingAlgorithmName: database_inline defaultTableStrategy: none: shardingAlgorithms: database_inline: type: INLINE props: algorithm-expression: ds_${user_id % 2} t_order_inline: type: INLINE props: algorithm-expression: t_order_${order_id % 2} t_order_view_inline: type: INLINE props: algorithm-expression: t_order_view_${order_id % 2} t_order_view2_inline: type: INLINE props: algorithm-expression: t_order_view2_${order_id % 2} t_item_inline: type: INLINE props: algorithm-expression: t_item_${id % 2} keyGenerators: snowflake: type: SNOWFLAKE ``` ``` mode: type: Cluster repository: type: ZooKeeper props: namespace: 0809-tablespace server-lists: 127.0.0.1:2181 retryIntervalMilliseconds: 500 timeToLiveSeconds: 60 maxRetries: 3 operationTimeoutMilliseconds: 500 overwrite: true rules: - !AUTHORITY users: - root@%:root - sharding@:sharding provider: type: ALL_PRIVILEGES_PERMITTED props: proxy-frontend-database-protocol-type: "openGauss" sql-show: true ``` `proxy execute CREATE TABLE t_order (order_id INT NOT NULL, user_id INT NOT NULL, status VARCHAR(45) NULL, PRIMARY KEY (order_id));` `ds0 execute drop table t_order_1;` `ds1 execute drop table t_order_0;` ` drop namespace in zk;restart proxy ` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
