You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Aman Sinha <as...@maprtech.com> on 2014/11/21 19:44:37 UTC
Rule abbreviations and enabling/disabling rules
I would like to be able to selectively enable/disable rules in a sqlline
session (for performance and functionality testing). In order to do that,
I can add a single configuration option in Drill and override the
matches() method in the derived rule class to check for this option.
However, I would like to avoid having to specify the full rule name since
the names could be rather long. Has there been any thought given to
creating canonical abbreviated rule names ? Each rule could implement an
abbreviatedName() method.
I understand there's more supporting logic needed than above, but I just
want to get a sense of whether other folks have felt the need for
enabling/disabling rules selectively ?
thanks,
Aman
Re: Rule abbreviations and enabling/disabling rules
Posted by Aman Sinha <as...@maprtech.com>.
Agree with the general ideas of the proposals. I will create 3 separate
JIRAs.
Aman
On Fri, Nov 21, 2014 at 1:11 PM, Julian Hyde <ju...@gmail.com> wrote:
> +1
>
> To enable/disable rules, I would create a wrapper Program, have it read a
> property which is a comma-separated list of regexps, and call a new method
> Program.enableRules(List<String> rules, boolean enable). This could be jira
> case #1.
>
> We already require rule classes to have canonical names. By default, we
> use the class name (sans package). We should tighten up and allow names to
> only include [A-Za-z0-9$_.]. (I would like to use /, [, ] as
> meta-characters, see below.) This could be jira case #2.
>
> Programs can be nested, and so there can be several instances of the same
> rule in the whole program. So, to disable specific instances we would need
> a unique identifier for a rule instance. We also need a way to print out
> the full program (including nested programs) that is being used. I suggest
> the following jira to solve both issues.
>
> a. Add an API to serialize a program as JSON. The serialized form would
> include rule instances, nested programs, and other nested structures (e.g.
> Hep has a constructs for sequences of rules, and for loops).
>
> The JSON would let people see what rules are being used from sqlline. (You
> can't disable a rule until you know which rules are used!)
>
> b. Each rule instance would have a path,
> /program1/programs[3]/loop/sequence[2]. So we could allow these full paths
> in the regexp comma-list described above.
>
> Jira case #3 would cover (a) and (b).
>
> Aman,
>
> If you agree, can you log these cases?
>
> Julian
>
>
>
> > On Nov 21, 2014, at 11:48 AM, Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
> >
> > +1 for ability to enable/disable rules.
> >
> > Not sure about canonical names.
> >
> > Another relevant nice to have feature is per query planning hints:
> > enable/disable rules, override statistics/selectivity/cost.
> >
> > Regards,
> > Vladimir Sitnikov
> > 21 нояб. 2014 г. 21:45 пользователь "Aman Sinha" <as...@maprtech.com>
> > написал:
> >
> >> I would like to be able to selectively enable/disable rules in a sqlline
> >> session (for performance and functionality testing). In order to do
> that,
> >> I can add a single configuration option in Drill and override the
> >> matches() method in the derived rule class to check for this option.
> >>
> >> However, I would like to avoid having to specify the full rule name
> since
> >> the names could be rather long. Has there been any thought given to
> >> creating canonical abbreviated rule names ? Each rule could implement
> an
> >> abbreviatedName() method.
> >>
> >> I understand there's more supporting logic needed than above, but I just
> >> want to get a sense of whether other folks have felt the need for
> >> enabling/disabling rules selectively ?
> >>
> >> thanks,
> >> Aman
> >>
>
>
Re: Rule abbreviations and enabling/disabling rules
Posted by Julian Hyde <ju...@gmail.com>.
+1
To enable/disable rules, I would create a wrapper Program, have it read a property which is a comma-separated list of regexps, and call a new method Program.enableRules(List<String> rules, boolean enable). This could be jira case #1.
We already require rule classes to have canonical names. By default, we use the class name (sans package). We should tighten up and allow names to only include [A-Za-z0-9$_.]. (I would like to use /, [, ] as meta-characters, see below.) This could be jira case #2.
Programs can be nested, and so there can be several instances of the same rule in the whole program. So, to disable specific instances we would need a unique identifier for a rule instance. We also need a way to print out the full program (including nested programs) that is being used. I suggest the following jira to solve both issues.
a. Add an API to serialize a program as JSON. The serialized form would include rule instances, nested programs, and other nested structures (e.g. Hep has a constructs for sequences of rules, and for loops).
The JSON would let people see what rules are being used from sqlline. (You can't disable a rule until you know which rules are used!)
b. Each rule instance would have a path, /program1/programs[3]/loop/sequence[2]. So we could allow these full paths in the regexp comma-list described above.
Jira case #3 would cover (a) and (b).
Aman,
If you agree, can you log these cases?
Julian
> On Nov 21, 2014, at 11:48 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
>
> +1 for ability to enable/disable rules.
>
> Not sure about canonical names.
>
> Another relevant nice to have feature is per query planning hints:
> enable/disable rules, override statistics/selectivity/cost.
>
> Regards,
> Vladimir Sitnikov
> 21 нояб. 2014 г. 21:45 пользователь "Aman Sinha" <as...@maprtech.com>
> написал:
>
>> I would like to be able to selectively enable/disable rules in a sqlline
>> session (for performance and functionality testing). In order to do that,
>> I can add a single configuration option in Drill and override the
>> matches() method in the derived rule class to check for this option.
>>
>> However, I would like to avoid having to specify the full rule name since
>> the names could be rather long. Has there been any thought given to
>> creating canonical abbreviated rule names ? Each rule could implement an
>> abbreviatedName() method.
>>
>> I understand there's more supporting logic needed than above, but I just
>> want to get a sense of whether other folks have felt the need for
>> enabling/disabling rules selectively ?
>>
>> thanks,
>> Aman
>>
Re: Rule abbreviations and enabling/disabling rules
Posted by Vladimir Sitnikov <si...@gmail.com>.
+1 for ability to enable/disable rules.
Not sure about canonical names.
Another relevant nice to have feature is per query planning hints:
enable/disable rules, override statistics/selectivity/cost.
Regards,
Vladimir Sitnikov
21 нояб. 2014 г. 21:45 пользователь "Aman Sinha" <as...@maprtech.com>
написал:
> I would like to be able to selectively enable/disable rules in a sqlline
> session (for performance and functionality testing). In order to do that,
> I can add a single configuration option in Drill and override the
> matches() method in the derived rule class to check for this option.
>
> However, I would like to avoid having to specify the full rule name since
> the names could be rather long. Has there been any thought given to
> creating canonical abbreviated rule names ? Each rule could implement an
> abbreviatedName() method.
>
> I understand there's more supporting logic needed than above, but I just
> want to get a sense of whether other folks have felt the need for
> enabling/disabling rules selectively ?
>
> thanks,
> Aman
>