ITE-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
> > > > > design before we pull the trigger.
> > >
> 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 already), and this change will help.
> > > &
ave 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
> > > >
> > > > On Sat, Mar 14, 2020 at 8:22 PM Haishe
t; > > > > > > .as(Config.class)
> > > > > > > > .toRule();
> > > > > > > >
> > > > > > > > Before we continue to the discussion and code review, we
> need to
> > > > go back
> > &g
new approach is awesome, let's go with it.
> > > > > > > [+0] Meh, I am OK with current approach, I don't see any burden or
> > > problem
> > > > > > > with it.
> > > > > > > [-1] Hell no, current approach is bad, the new one is even worse.
> > > > > > >
> > > > > >
> > > > > > > of a rule with different properties) you would have to call the
> > rule's
> > > > > > > constructor. Frequently the required constructor did not exist,
> > so we
> > > > > > > would have to ad
les, which used to contain
> many
> > > > > > sub-classes. Those sub-classes are no longer needed. Old code:
> > > > > >
> > > > > > public static final DruidSortProjectTransposeRule
> > > > > SORT_PROJECT_TRANSPOSE =
> > > > > > new
> D
roject.class, operand(DruidQuery.class,
> > > > none(,
> > > > > relBuilderFactory, null);
> > > > > }
> > > > > }
> > > > >
> > > > > New code:
> > > > >
> > > > > public s
TER_ON_JOIN.get().
> > > >
> > > > Julian
> > > >
> > > >
> > > > On Thu, Apr 16, 2020 at 12:08 PM Julian Hyde wrote:
> > > > >
> > > > > I have now pushed a dev branch with a prototype. Please see
> > > > > https://issues.apache.org/jira/browse/CA
> Haisheng,
> > > > >
> > > > > I hear you. I agree that major changes to rules will require new rule
> > > > > classes (not merely sub-classes). People should copy-paste, refactor,
> > > > > and all that good stuff. But I think there are
king 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
> > > >
> > > > 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 a different parameter,
> > > > they most l
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.
> > >
> > > - Haisheng
&g
> > - Haisheng
> >
> > ----------------------
> > 发件人：Stamatis Zampetakis
> > 日 期：2020年03月14日 22:54:04
> > 收件人：
> > 主 题：Re: [DISCUSS] Refactor how planner rules are parameterized
> >
> > Hello,
> &
tly 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
> 收件人：
>
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 realised that I
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
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
18 matches
Mail list logo
