This sounds reasonable to me. It also sounds like we could make this
backwards compatible by retaining (but deprecating) the existing
constructors and factory methods that will no longer be needed.
--
Michael Mior
mm...@apache.org
Le jeu. 20 févr. 2020 à 13:11, Julian Hyde a écrit :
>
> I have an
Hello,
Apologies for the late reply but I just realised that I had written the
mail and never pressed the send button.
I think it is a nice idea and certainly a problem worth addressing. If I
understood well you're thinking something like the current constructor of
the RelBuilder [1] that accepts
reusable even with flexible
configurations.
- Haisheng
--
发件人：Stamatis Zampetakis
日 期：2020年03月14日 22:54:04
收件人：
主 题：Re: [DISCUSS] Refactor how planner rules are parameterized
Hello,
Apologies for the late reply but I just reali
some slightly their
> own logic. For many Calcite users, the rule is not reusable even with
> flexible configurations.
>
> - Haisheng
>
> --
> 发件人：Stamatis Zampetakis
> 日 期：2020年03月14日 22:54:04
> 收件
> >
> > - Haisheng
> >
> > --------------------------
> > 发件人：Stamatis Zampetakis
> > 日 期：2020年03月14日 22:54:04
> > 收件人：
> > 主 题：Re: [DISCUSS] Refactor how planner rules are parameterized
> >
> > Hello,
7;t be satisfied by a different parameter,
> > > they most likely still need to rewrite (copy & paste) the rule with some
> > > slightly their own logic. For many Calcite users, the rule is not
> > > reusable even with flexible configurations.
> > >
> >
gt; > >
> > > On Sat, Mar 14, 2020 at 8:22 PM Haisheng Yuan
> > > wrote:
> > > >
> > > > I don't think it is worth the refactoring. People who want to customize
> > > > the rule, in most cases, won't be satisfied by
browse/CALCITE-3923 and
> > > > am going to start working on a prototype. When we have a prototype we
> > > > will be able to assess how big an impact the API change will have.
> > > > (E.g. whether it will be a breaking change.)
> > > >
> > > &g
Apr 14, 2020 at 2:06 PM Julian Hyde wrote:
> > > > >
> > > > > Haisheng,
> > > > >
> > > > > I hear you. I agree that major changes to rules will require new rule
> > > > > classes (not merely sub-classes). People should cop
tRule to
> > > > Supplier, to avoid deadlocks during class loading. For
> > > > instance, instead of writing FilterJoinRule.FILTER_ON_JOIN you must
> > > > now write FilterJoinRule.FILTER_ON_JOIN.get().
> > > >
> > > > Julian
> > > >
> > > >
> > > > On Thu,
poseRule(RelBuilderFactory
> > > > > relBuilderFactory) {
> > > > > super(
> > > > > operand(Sort.class,
> > > > > operand(Project.class, operand(DruidQuery.class,
> > > > none(,
> > > > >
t; > > > constructors are now private, because only the configuration ever
> > > > > > calls them.)
> > > > > >
> > > > > > A good illustration of this is DruidRules, which used to contain
> many
> > > > > > sub-classes. Those sub-classes are no longer n
gt; >
> > > > > > > Previously, it was not easy to customize, re-use or extend
> > planner
> > > > > > > rules. If you wished to customize a rule (i.e. create a new
> > instance
> > > > > > > of a rule wi
ey to see how Calcite devs and users think? Then let's
> > > see how to
> > > > > > > move forward.
> > > > > > >
> > > > > > > [+1] Hell yeah, the new approach is awesome, let's go with it.
> > > > > > > [+0] Meh, I am OK with current approach, I don't see any burden o
gt; > > > > > > > .oneInput(b1 ->
> > > > b1.operand(CassandraTableScan.class)
> > > > > > > > .noInputs()))
> > > > > > > > .as(Config.class)
> > > > > > >
m going to start working on a prototype. When we have a prototype we
> > > > will be able to assess how big an impact the API change will have.
> > > > (E.g. whether it will be a breaking change.)
> > > >
> > > > Julian
> > > >
> >
ot merely sub-classes). People should copy-paste,
> refactor,
> > > > > and all that good stuff. But I think there are a lot of cases
> where we
> > > > > need to make minor changes to rules (there are many of these in the
> > > > > code base alr
t; > > > https://issues.apache.org/jira/browse/CALCITE-3923 for details.
> > > > >
> > > > > Having built the prototype, I believe that this change is beneficial
> > > > > and we should do it. But I would like to get to consensus on the
> > >
18 matches
Mail list logo
