[ https://issues.apache.org/jira/browse/CALCITE-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Hyde updated CALCITE-3923: --------------------------------- Fix Version/s: 1.24.0 > Refactor how planner rules are parameterized > -------------------------------------------- > > Key: CALCITE-3923 > URL: https://issues.apache.org/jira/browse/CALCITE-3923 > Project: Calcite > Issue Type: Bug > Reporter: Julian Hyde > Assignee: Julian Hyde > Priority: Major > Fix For: 1.24.0 > > Time Spent: 10m > Remaining Estimate: 0h > > People often want different variants of planner rules. An example is > {{FilterJoinRule}}, which has a 'boolean smart’ parameter, a predicate (which > returns whether to pull up filter conditions), operands (which determine the > precise sub-classes of {{RelNode}} that the rule should match) and a > {{RelBuilderFactory}} (which controls the type of {{RelNode}} created by this > rule). > Suppose you have an instance of {{FilterJoinRule}} and you want to change > {{smart}} from true to false. The {{smart}} parameter is immutable (good!) > but you can’t easily create a clone of the rule because you don’t know the > values of the other parameters. Your instance might even be (unbeknownst to > you) a sub-class with extra parameters and a private constructor. > So, my proposal is to put all of the config information of a {{RelOptRule}} > into a single {{config}} parameter that contains all relevant properties. > Each sub-class of {{RelOptRule}} would have one constructor with just a > ‘config’ parameter. Each config knows which sub-class of {{RelOptRule}} to > create. Therefore it is easy to copy a config, change one or more properties, > and create a new rule instance. > Adding a property to a rule’s config does not require us to add or deprecate > any constructors. > The operands are part of the config, so if you have a rule that matches a > {{EnumerableFilter}} on an {{EnumerableJoin}} and you want to make it match > an {{EnumerableFilter}} on an {{EnumerableNestedLoopJoin}}, you can easily > create one with one changed operand. > The config is immutable and self-describing, so we can use it to > automatically generate a unique description for each rule instance. > (See the email thread [[DISCUSS] Refactor how planner rules are > parameterized|https://lists.apache.org/thread.html/rfdf6f9b7821988bdd92b0377e3d293443a6376f4773c4c658c891cf9%40%3Cdev.calcite.apache.org%3E].) -- This message was sent by Atlassian Jira (v8.3.4#803005)