strongduanmu commented on a change in pull request #10193: URL: https://github.com/apache/shardingsphere/pull/10193#discussion_r622667824
########## File path: shardingsphere-features/shardingsphere-sharding/shardingsphere-sharding-route/src/main/java/org/apache/shardingsphere/sharding/route/engine/validator/ddl/impl/ShardingAlterTableStatementValidator.java ########## @@ -0,0 +1,68 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.shardingsphere.sharding.route.engine.validator.ddl.impl; + +import org.apache.shardingsphere.infra.binder.statement.SQLStatementContext; +import org.apache.shardingsphere.infra.binder.type.TableAvailable; +import org.apache.shardingsphere.infra.exception.ShardingSphereException; +import org.apache.shardingsphere.infra.metadata.schema.ShardingSphereSchema; +import org.apache.shardingsphere.infra.route.context.RouteContext; +import org.apache.shardingsphere.sharding.route.engine.validator.ddl.ShardingDDLStatementValidator; +import org.apache.shardingsphere.sharding.rule.ShardingRule; +import org.apache.shardingsphere.sharding.rule.TableRule; +import org.apache.shardingsphere.sql.parser.sql.common.statement.ddl.AlterTableStatement; + +import java.util.Collection; +import java.util.List; +import java.util.stream.Collectors; + +/** + * Sharding alter table statement validator. + */ +public final class ShardingAlterTableStatementValidator extends ShardingDDLStatementValidator<AlterTableStatement> { + + @Override + public void preValidate(final ShardingRule shardingRule, final SQLStatementContext<AlterTableStatement> sqlStatementContext, final List<Object> parameters, final ShardingSphereSchema schema) { + Collection<String> shardingLogicTableNames = getShardingLogicTableNames(shardingRule, sqlStatementContext); + if (shardingLogicTableNames.size() <= 1) { + return; + } Review comment: > How about `broadcast Table`or `single table`? > Is #10172 a interim solution? @tristaZero Sorry for late reply, I spent some time sorting out the different scenes. According to the table type, there are sharding, broadcast and single table in SS. By combining with Cartesian product, we can get nine combination types. case | primary table | referenced table -- | -- | -- 1 | sharding | sharding 2 | sharding | broadcast 3 | sharding | single 4 | broadcast | sharding 5 | broadcast | broadcast 6 | broadcast | single 7 | single | sharding 8 | single | broadcast 9 | single | single ## case 1: sharding * sharding There are two situations in this scenario. The sharding tables can be binding tables or unbinding tables. Binding table's routing logic is consistent with current logic. The only difference is that the logic is advanced to the route module for processing. Routing of the primary table is processed first, and then other binding tables are also routed with the same rule according to the binding relationship. The routing logic of the unbinding tables use the Cartesian product way, but some routing results are illegal for DDL statements. Suppose we have the following sharding configuration. ```yaml rules: - !SHARDING tables: t_order: actualDataNodes: test_${0..1}.t_order_${0..1} tableStrategy: standard: shardingColumn: order_id shardingAlgorithmName: t_order_inline keyGenerateStrategy: column: order_id keyGeneratorName: snowflake t_order_item: actualDataNodes: test_${0..1}.t_order_item_${0..1} tableStrategy: standard: shardingColumn: order_id shardingAlgorithmName: t_order_item_inline keyGenerateStrategy: column: order_item_id keyGeneratorName: snowflake ``` The table of `t_order` and `t_order_item` are not binding tables. After routing, we will get the following results. Obviously, we can not execute the `alter table t_order_item_1 add constraint t_order_fkey ... ` statement multiple times under the same data source. Therefore, this routing result needs to throw an exception in the `postValidate` method. BTW, this validate logic is also applicable to other scenarios where Cartesian product routing is used. ``` [INFO ] 2021-04-28 17:22:13.853 [pool-21-thread-1] ShardingSphere-SQL - Actual SQL: test_0 ::: alter table t_order_item_1 add constraint t_order_fkey foreign key (order_id) references t_order_0 (order_id) [INFO ] 2021-04-28 17:22:13.854 [pool-21-thread-1] ShardingSphere-SQL - Actual SQL: test_0 ::: alter table t_order_item_1 add constraint t_order_fkey foreign key (order_id) references t_order_1 (order_id) [INFO ] 2021-04-28 17:22:13.854 [pool-21-thread-1] ShardingSphere-SQL - Actual SQL: test_0 ::: alter table t_order_item_0 add constraint t_order_fkey foreign key (order_id) references t_order_0 (order_id) [INFO ] 2021-04-28 17:22:13.854 [pool-21-thread-1] ShardingSphere-SQL - Actual SQL: test_0 ::: alter table t_order_item_0 add constraint t_order_fkey foreign key (order_id) references t_order_1 (order_id) [INFO ] 2021-04-28 17:22:13.854 [pool-21-thread-1] ShardingSphere-SQL - Actual SQL: test_1 ::: alter table t_order_item_1 add constraint t_order_fkey foreign key (order_id) references t_order_0 (order_id) [INFO ] 2021-04-28 17:22:13.854 [pool-21-thread-1] ShardingSphere-SQL - Actual SQL: test_1 ::: alter table t_order_item_1 add constraint t_order_fkey foreign key (order_id) references t_order_1 (order_id) [INFO ] 2021-04-28 17:22:13.854 [pool-21-thread-1] ShardingSphere-SQL - Actual SQL: test_1 ::: alter table t_order_item_0 add constraint t_order_fkey foreign key (order_id) references t_order_0 (order_id) [INFO ] 2021-04-28 17:22:13.854 [pool-21-thread-1] ShardingSphere-SQL - Actual SQL: test_1 ::: alter table t_order_item_0 add constraint t_order_fkey foreign key (order_id) references t_order_1 (order_id) ``` There are also some special sharding config, such as the sharding rules that only configure a single data node. ```yaml rules: - !SHARDING tables: t_order: actualDataNodes: test_0.t_order_0 t_order_item: actualDataNodes: test_0.t_order_item_0 ``` When Cartesian product routing is used in this scenario, the abnormal routing results described above will not occur, so it can be executed normally. ``` [INFO ] 2021-04-28 17:22:13.854 [pool-21-thread-1] ShardingSphere-SQL - Actual SQL: test_0 ::: alter table t_order_item_0 add constraint t_order_fkey foreign key (order_id) references t_order_0 (order_id) ``` ## case 2: sharding * broadcast ## case 3: sharding * single ## case 4: broadcast * sharding ## case 5: broadcast * broadcast ## case 6: broadcast * single ## case 7: single * sharding ## case 8: single * broadcast ## case 9: single * single -- 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
