[
https://issues.apache.org/jira/browse/CALCITE-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17618889#comment-17618889
]
Stamatis Zampetakis commented on CALCITE-5332:
----------------------------------------------
Thanks for the feedback [~julianhyde] .
At the moment:
* all built-in rules in the repo come with at least one DEFAULT config instance
* the Javadoc asks for devs to create a DEFAULT configuration instance for
each new rule
Based on the above, I am inclined to merge the current PR (adding DEFAULT
configs in PruneEmptyRule) simply to align these rules with the rest of the
code base.
Guiding users to use a certain pattern when creating rules is an interesting
discussion but it may be larger than the scope of this JIRA. I am happy to do
it here, but it may be better to do it in the dev list or under a dedicated
Jira. Most likely we will need to adapt/introduce documentation and revisit
parts of our code base to make that happen. People tend to copy existing
patterns existing from the calcite-core, so if there we build rules starting
from DEFAULT config instances, then this is what others will do in projects
using Calcite (given that all config instances are public).
> Configuring PruneEmptyRules is cumbersome
> -----------------------------------------
>
> Key: CALCITE-5332
> URL: https://issues.apache.org/jira/browse/CALCITE-5332
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.32.0
> Reporter: Stamatis Zampetakis
> Assignee: Stamatis Zampetakis
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.33.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After CALCITE-4787/CALCITE-4839 (release 1.28.0) it is pretty complicated to
> create new PruneEmptyRule instances with slightly different configurations.
> The most common use-case is to modify a rule, for instance
> [PruneEmptyProject|https://github.com/apache/calcite/blob/2c30a56158cdd351d35725006bc1f76bb6aac75b/core/src/main/java/org/apache/calcite/rel/rules/PruneEmptyRules.java#L178],
> and change the operands to enlarge or restrict the matching scope; e.g.,
> instead of matching the general {{Project.class}} match only
> {{HiveProject.class}}.
> At the moment this task is not straightforward for various reasons.
> We cannot create the new rule by obtaining the configuration from the
> existing instance (e.g., PROJECT_INSTANCE) cause the latter is declared as
> RelOptRule. Unless we cast the instance to {{RelRule}} we cannot get access
> to its configuration and change it.
> {{ImmutableRemoveEmptySingleRuleConfig}} is package private as every other
> immutable class so again we cannot start from there.
> The constructors of {{RemoveEmptySingleRule}} are either deprecated or
> package private so cannot/should not be used.
> [RemoveEmptySingleRuleConfig|https://github.com/apache/calcite/blob/2c30a56158cdd351d35725006bc1f76bb6aac75b/core/src/main/java/org/apache/calcite/rel/rules/PruneEmptyRules.java#L351]
> does not provide a {{DEFAULT}} configuration instance.
> The only way "recommended" way to create a new rule instance at the moment is
> to implement the respective config interface. This is unnecessary and
> requires quite a bit of work if the consumer is not using the immutables
> library annotation processor.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
