gianm commented on code in PR #12715: URL: https://github.com/apache/druid/pull/12715#discussion_r914056125
########## sql/src/main/java/org/apache/druid/sql/calcite/rule/DruidExtensionCalciteRuleManager.java: ########## @@ -0,0 +1,54 @@ +/* + * 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.druid.sql.calcite.rule; + +import com.google.common.collect.ImmutableList; +import com.google.inject.Inject; +import org.apache.calcite.plan.RelOptRule; +import org.apache.druid.sql.calcite.planner.PlannerContext; + +import java.util.List; +import java.util.Set; + +/** + * Manages the custom calcite rules coming from extensions + */ +public class DruidExtensionCalciteRuleManager +{ + private final Set<DruidExtensionCalciteRuleProvider> druidExtensionCalciteRuleProviderSet; + + @Inject + public DruidExtensionCalciteRuleManager( + Set<DruidExtensionCalciteRuleProvider> druidExtensionCalciteRuleProviderSet + ) + { + this.druidExtensionCalciteRuleProviderSet = druidExtensionCalciteRuleProviderSet; + } + + public List<RelOptRule> updateDruidConventionRuleSet(PlannerContext plannerContext, List<RelOptRule> coreRules) Review Comment: > We did it this way so that this code could potentially replace rules if it wanted to. With the way you are suggesting, rules can be added, but if there is something that needs adjustment in one of the rules already registered, it's not possible to effect that. But it also couldn't be done with the current code, right? In the current code the manager is a concrete class, not an interface. So there isn't a clean way for an extension to change this to replace rules. Unless I'm missing something? Anyway, regardless of that, I do think the current code in the patch is fine. It just looks funny and I'm not sure if it really accomplishes the goal of enabling extensions to replace rules. To me it'd make more sense if there was a specific interface for that, either with a Set (so multiple extensions could register rule-replacements) or a PolyBind (so one extension gets to be in charge of rule-replacement). So, it's ok with me if it stays as is, but if it does I'd like to see some comments about the intent here, to counteract the "funny-lookingness". > @gianm : Can we move DruidExtensionCalciteRuleManager to CalciteRuleManager? It can then provide the rule set for both druid and bindable convention - hence being the main logic to assemble planning rules. Currently we're allowing to augment druid convention rules, in future it could also support bindable convention rules from extensions if needed. Sure, that makes sense to me. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
