This is useful, though Hive will have to do some refactoring. In past Hive had to copy bunch of rules to work around these issues. Rules & relnodes for org.apache.calcite.rel.logical.* is a good example of this.
John On 9/22/15, 5:14 PM, "Julian Hyde" <[email protected]> wrote: >I have started work on >https://issues.apache.org/jira/browse/CALCITE-828 and my >work-in-progress is in >https://github.com/julianhyde/incubator-calcite/commits/828-rule-builder. > >This will be a big change to teams such as Hive and Drill. Now would >be a good time to chime in. > >The plan is that every rule instance has a ProtoRelBuilder field from >which a RelBuilder can be created to be used in an onMatch method. The >RelBuilder contains factories for every kind of RelNode, so we won't >have to keep plumbing new factories in to existing rules. > >There will be other advantages. RelBuilder is an easier and more >concise way of creating relational expressions. It does some useful >stuff for free, like flattening ANDs and eliminating identity >projections. I'm seeing the volume of code decrease and a few minor >plan improvements. > >I haven't yet found a good way to deal with the pattern where if, say, >ProjectFactory is null the rule is to use Project.copy to create a >Project of the same type. > >I'm keeping & deprecating the old rule constructors that take a >variety of XxxFactory arguments. > >As always, we try to keep API compatibility and mark the old API > > @Deprecated // to be removed before 2.0 > >but the deprecated APIs are no longer tested and are likely to be >flaky. We strongly suggest that you fix calls to deprecated APIs as >soon as you upgrade to a more recent version of Calcite. > >Julian >
