[
https://issues.apache.org/jira/browse/CALCITE-828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-828.
---------------------------------
Resolution: Fixed
Fix Version/s: 1.5.0-incubating
Fixed in
http://git-wip-us.apache.org/repos/asf/incubator-calcite/commit/815fa262. Note
that there are a few breaking changes in that commit.
> Use RelBuilder in rules rather than type-specific RelNode factories
> -------------------------------------------------------------------
>
> Key: CALCITE-828
> URL: https://issues.apache.org/jira/browse/CALCITE-828
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Julian Hyde
> Fix For: 1.5.0-incubating
>
>
> Many planner rules create filters, projects, joins, ... and over the years
> people have made them generic, so they can create different particular
> sub-classes of RelNodes (say DrillFilter or HiveProject) by adding factories
> (interfaces defined in RelFactories).
> But then people extend a rule, so that a rule that used to only create
> projects now might sometimes create a filter. They now need to add an extra
> parameter to the instance of the rule, which is painful. Also, rules may call
> into utility methods such as RelOptUtil.pushDownJoinConditions (see
> CALCITE-826), which have similar problems.
> The solution is to get rid of factories in public interfaces and instead pass
> around a RelBuilder. A particular instance of RelBuilder has a factory inside
> it for each type of RelNode. In general a particular client of Calcite (e.g.
> Hive) will be able to use the same RelBuilder throughout a query.
> Rules are static, so a rule instance cannot contain a RelBuilder, only a
> ProtoRelBuilder, which can create a RelBuilder given a RelOptCluster and
> RelOptSchema.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
