Agree on the utility of this. +1. On Tue, Sep 22, 2015 at 6:22 PM, John Pullokkaran < [email protected]> wrote:
> 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 > > > >
